Slashdot Mirror

And welcome. Just wanted to make a programming suggestion since you are an ASP and database guy. Check out the Zope application server ( and I'll tell you now so you don't have to stumble on it your self: Get ZEO when you get Zope ). Zope is a python based webserver. Very cool stuff. Also, start converting your ASP experience into Apache's PHP experience. Finally, take a look at Postgres SQL server. These products should get you started in delivering solutions similiar to the ones your working on now.

And don't be daunted by the learning curve of Linux. It is worth it in the end. ( but there is no end, hehe )

Kind Regards

And welcome. Just wanted to make a programming suggestion since you are an ASP and database guy. Check out the Zope application server ( and I'll tell you now so you don't have to stumble on it your self: Get ZEO when you get Zope ). Zope is a python based webserver. Very cool stuff. Also, start converting your ASP experience into Apache's PHP experience. Finally, take a look at Postgres SQL server. These products should get you started in delivering solutions similiar to the ones your working on now.

And don't be daunted by the learning curve of Linux. It is worth it in the end. ( but there is no end, hehe )

Kind Regards

Moving from C++ to Java results in a 2x improvement in programmer productivity, he says, while the move from C++ to Python results in a 5x to 10x improvement. He is still developing his reasons as to why this is the case, but he believes that Python allows a programmer to focus on concepts, rather than on mechanics.

Lacking any scientific studies, Bruce offered his top ten reasons why he loves Python:

10. Reduced Clutter - The indented nature of Python makes it easier to read, an important criteria since code is read more often than it is written. According the the extreme programming (XP) folks, consistant formatting really is important.

9. It's not Backward Compatible in Exchange for Pain - Many popular languages promote their backward compatability, but at the cost to the programmer of awkward syntax (C++ and Perl) and lots of typing (Java).

8. It Doesn't Value Performance Over Productivity - Rather than forcing the programmer to implement awkward coding sequences for the sake of "speed," Python implements easy-to-learn idioms (but allows extensions to be written in C when performance becomes an issue).

7. It Doesn't Treat Me Like I'm Stupid - Python doesn't prevent operator overloading, doesn't insist on type declarations, and it doesn't pretend to be something that it isn't.

6. I Don't Wait Forever for a Full Implementation of the Language - C++ still does not fully implement features invented by the C++ committee.

5. It Does Not Make Assumptions About How We Discover Errors - Python does not force static type checking, moving the programmer quickly along to the discovery of errors using "real" data.

4. Marketing People Are Not Involved... Yet -- Java and MS Visual C++ have been over-hyped.

3. I Don't Have to Type So Much - Not obscure like APL, not endlessly inventive like Perl or FORTH, not verbose like Java.

2. My Guesses are Usually Right - Java and C++ require programmers to constantly look up syntax in a language reference. Python idioms are easier.

1. Python Let Me Focus on Concepts - No stumbling through Java designs, no fighting with C++ compilations or runtime bugs."

PS...if you've been living under a rock, Zope is the Open Source Application server and is Python's "killer app". Also, Bruce's books are available for free online and available from mirrors listed at http://www.mindview.net/DownloadSites/

Curious George

The poster who pointed out the relatively new O'Reilly OnLAMP site hit the crux of the matter, in my opinion. Tim O'Reilly's more interested in driving and promoting promising new technologies than creating them. (I suspect that's why the company has invested in Digital Creations, the people behind Zope.)

On the other hand, the Python, Java, and Perl advocacy (with books and conferences) are dedicated to promoting existing technologies. Either way, it seems that Tim's focus is on evangelizing good technology.

--

If, like me, you have your companies intranet deployed on Zope, then you need to check out the excellently simple Meerkat client for Zope. It's a nice little utility that (among other things) caches the expensive XML-RPC queries to the Meerkat server.
--

If, like me, you have your companies intranet deployed on Zope, then you need to check out the excellently simple Meerkat client for Zope. It's a nice little utility that (among other things) caches the expensive XML-RPC queries to the Meerkat server.
--

Also, there's a good XML-RPC HOWTO and Meerkat HOWTO plus several XML-PRC related pages available at zope.org.
--

Also, there's a good XML-RPC HOWTO and Meerkat HOWTO plus several XML-PRC related pages available at zope.org.
--

Also, there's a good XML-RPC HOWTO and Meerkat HOWTO plus several XML-PRC related pages available at zope.org.
--

Also, there's a good XML-RPC HOWTO and Meerkat HOWTO plus several XML-PRC related pages available at zope.org.
--

Hmm, I just don't have the time know to find out what this MS DD really is, but take a look at zope (the look should last a little longer, zope is very powerfull).
Zope provides object serialization with various methods, one of that is xml. Objects build web pages in zope (in fact, everything in zopes object database is an object/method).
It also does SOAP/xmlrpc/DAV, has session-management (as of zope 2.3) and - to get ontopic again - it's IMO a perfect platform for developing a groupware on. One "just" needed to write a dedicated client in order to surpass any limits which a normal browser might have for that task.
Search for zopeGUM, it's a groupware in development.

I don't think .NET has been released yet, though. As for the "open source hype", well, I am using open source technology exclusively on our systems at work and it has been an extremely successful venture. To give you some idea, we have up to 5,000 mail accounts running on exim, 3,000 shell accounts, run an industrial strength DNS system, industrial strength, internally developed network management systems running on Zope/Python, and a staunch news server all running off an 8-node MOSIX cluster.

-bp

Of course, perhaps the next version of Perl will include the ease-of-use and clean-factor of Python. Perhaps the next version of Perl will allow ultra-fast development time and allow programmers to do what they enjoy most: look after their polo ponies, and not have to spend weeks developing applications that would take 3 days in Python and Zope.

Products like Zope and Modsnake, as well as propreitry solutions like Allaire's ColdFusion and Vignettes' Story Server, will enable applications to be distributed via networked computers. This will allow current technology to run applications of tommorrow without huge infrastructure upgrades.

Just my 2c

Matt Barnson

Zope GUM, Zope Grand Unified Messenger, does a lot of what you require, and will probably be compatible with most mainstream calendaring, mail, etc. servers as time goes by.

If you ask Jon Udell, the web services are already here. The latest buzzword advances with XML, SOAP, XML-RPC, and friends are all just further refinement and evolution of the interface. Also, Udell's book, Practical Internet Groupware, talks extensively about adapting existing sites into web services. For example, a site like MetaCrawler demonstrates this in how it uses search engines' HTML "interface" to scoop up search results. Or, take the scripts that query news sites without the benefit of RDF or RSS, parsing HTML to scoop up and aggregate news headlines. These are all primitive web services.

And this is not to mention app servers such as Zope and Frontier, which are already built to offer web services natively. It just seems irresistable to use all of these simple building blocks to create neato keen distributed systems...

I'm not sure why it would mean that.
Zope and Zend are not related. (Apart from being in similar product spaces)

Zend is the company behind the latest PHP offerings.
Zope is a product from Digital Creations, that provides similar features to PHP (similar in the sense that it's about dynamic web-page generation).

Zope is OpenSource, with quite a reasonable license.

I certainly hope the Python doesn't go down the path of semi-open-source the way some products have, but I have faith that Guido wouldn't agree to that, and the new non-profit that will be taking on the Python copyright will probably have some safe guards in place to stop it.

--

We're trying hard to achieve a complete open development process on dev.zope.org. We call it the Fishbowl. It was started this year and so far has been quite successful. It is a way to open to the community not only the software but also the development process. Everyone has the opportunity to contribute at each phase.

Perhaps the most interesting part is the Proposals page. It allows anyone to contribute and discuss ideas for the development of Zope and related projects.

Some of the technology behind it, such as ZWiki and the CVS infrastructure, are not yet complete, but most don't see that as a barrier.

I think many open source projects would benefit from a similar methodology.

We're trying hard to achieve a complete open development process on dev.zope.org. We call it the Fishbowl. It was started this year and so far has been quite successful. It is a way to open to the community not only the software but also the development process. Everyone has the opportunity to contribute at each phase.

Perhaps the most interesting part is the Proposals page. It allows anyone to contribute and discuss ideas for the development of Zope and related projects.

Some of the technology behind it, such as ZWiki and the CVS infrastructure, are not yet complete, but most don't see that as a barrier.

I think many open source projects would benefit from a similar methodology.

We're trying hard to achieve a complete open development process on dev.zope.org. We call it the Fishbowl. It was started this year and so far has been quite successful. It is a way to open to the community not only the software but also the development process. Everyone has the opportunity to contribute at each phase.

Perhaps the most interesting part is the Proposals page. It allows anyone to contribute and discuss ideas for the development of Zope and related projects.

Some of the technology behind it, such as ZWiki and the CVS infrastructure, are not yet complete, but most don't see that as a barrier.

I think many open source projects would benefit from a similar methodology.

We're trying hard to achieve a complete open development process on dev.zope.org. We call it the Fishbowl. It was started this year and so far has been quite successful. It is a way to open to the community not only the software but also the development process. Everyone has the opportunity to contribute at each phase.

Perhaps the most interesting part is the Proposals page. It allows anyone to contribute and discuss ideas for the development of Zope and related projects.

Some of the technology behind it, such as ZWiki and the CVS infrastructure, are not yet complete, but most don't see that as a barrier.

I think many open source projects would benefit from a similar methodology.

The whole premise is faulty....
OSS and commercial software are orthogonal, so it's not possible to construct contradistinction between the two (...whereas open source ...).
For a good example go to http://dev.zope.org.
Zope _is_ open source _and_ commercial, and they put a lot of thought into how they want the development process to progress. Heck, read about the "fishbowl" in the above link, there are also thoughts about the progression of the planning of development.

Not to say this all works perfect (which is also always the case for closed-source projects), but open source doesn't mean that the software grows like cancer in any direction possible.

But true content management and workflow support are things that neither CVS, Zope, or wiki have. Slow down Slashdot.

Zope's very own Portal Toolkit (PTK) adds workflow processes.

Check it out here.

I haven't read it though, not enough time to play with ALL the fun stuff.

It may require more work, but two modes (i.e., flash/non-flash, text-only/graphical) may just be the easiest way to go -- so long as the content is identical in both modes. I imagine a site with fewer toys is easier to make accessible.

A nice way to manage multiple versions of the same site is to use server-side tools such as UserLand Frontier (which I used to use to manage my static site), PHP, Zope, or any of the many others out there -- these three are the ones I've tried. With a bit of scripting, you can get a good idea of what tricks you can use with a particular client, and tailor the page you serve to that client.

Building static sites with the same capabilities is harder -- as far as I can tell, there are very few tools for building nice sites offline and then uploading them to a remote server. (As I said, I used to use Frontier (which is (1) expensive, and (2) Mac/Windows only), and am currently frustrating myself by trying to bend Zope to my will (made hard by the lack of basic documentation) -- suggestions for alternatives are very welcome!)

Why do you need it to compile? I've written several production servers in python. When the limiting factor is I/O, the scripted/compiled performance difference is largely irrelevant.

Does this ean that you don't consider Zope a "real" application? How about sketch?? Programs don't always have to be compiled to be useful.

...Python and Perl aren't really languages that should be used for long-term stuff that requires maintenance anyway.

Well, it seems to me that zope qualifies as long-term stuff.

I've seen a lot of systems popping up on the web over the last few years to allow dynamic additions of content to an information system. Things that allow commentary to be added to webpages, which others can then view; sites like Everything or Everything2.

Why not such a system for documenting code? I know that systems for publishing and linking code to itself exists (like LXR). How about such a system that would allow links to be placed in the text to user-contributed documentation? Said documentation could be anything from "this statement is doing such-and-such" to an overview of an entire module.

This documentation would be user-contributed and, of course, user edited. Editing would need to be done based on a voting system... just saying whether a given bit of doc is useful ought to be enough. Attribution is easily done, as well.

The hardest bit would probably be telling the system where you want to place a link. Do you want to doc the line? The function definition? That word? These 3 functions? That bit of code and that one over there in a different file that happen to work together? Where does the link go?

Anyone have an idea on how to do that? I know I'm up for contributing to the development of such a system (playing with Zope has gotten me interested in dynamic web stuff).
---

The real solution for the future is WebDAV (and being worked on by the W3C), which fully supports named servers and authentication, and is designed to replace FTP and the various ugly "web posting" systems out there, including the uploading aspects of FrontPage Extensions.

Notably WebDAV implementations include Zope and mod_dav for Apache.

You might want to check out Zope. Digital Creations took a moderately successful commercial product, and turned it into a category killer by open sourcing it. Here is their account of how the decision was reached, and here is a presentation.
--

You might want to check out Zope. Digital Creations took a moderately successful commercial product, and turned it into a category killer by open sourcing it. Here is their account of how the decision was reached, and here is a presentation.
--

I'm not an hard core developer myself but when "weblications" are concerned: don't we got Zope to handle these things allready? One of its main advantages is at least the fact that its totally independent because it uses a browser for its primary interface.

A crucial piece of the puzzle isn't just another relational database; the catch is full-text and field indexing everything, prefereably in a full-text XML format; there are not any full-text search engines that are open source that work outside of the scope of a standard web site; what is needed is more of a repository, where XML-based content is stored and automatically indexed, so that records of multiple types and/or XML DTDs can be stored in one searchable repository.

In short, Libraries need a car-catalog system built on a foundtation of a digital asset management system; something which I haven't found many foundations for in current OSS projects. Commercial examples of such a beast might include Folio Livepublish, which is an "infobase" indexing and search engine that creates "repositories" or document collections that are fielda nd full-text searchable; a lot of people uses this type of stuff for electronic publishing and for knowledge-managment apps. I've used LivePublish as a developer/integrator/OEM at my previous employer. I don't particulaly like LivePublish, because it is (in my mind) unstable (it's an NT app), and the company that makes it has a rather rediculous royalty-based revenue model, but the product has some good ideas (like collecting content of multiple types into one repository, filtering binary types like word docs and PDFs so that they too can get indexed, fielded XML searches within elements); I think an OSS equivalent to something like this would be a great option for those of us who like some ideas that come out of commercial development firms, but don't like the rancid business models, crazy prices, and poor support of such companies.

The only architecture that even comes close to provinding the means to so this sort of thing is Zope, but Zope doesn't currently have field-searchable XML indexing; when Zope gets it, given it's a strong persistent object system (not to mention its ease of use with RDBMS systems and clean multi-tier development), then it would be an ideal architecture for building a libary card catalog system on top of.

Standardized (albeit by Sun), extensible APIs, especially on the server end, and extensible products, is part of what makes Java thrive today. Transaction API, J2EE, JNDI, Java2D/imaging, Java3D, servlets, JDBC, CORBA. Plus a host of pre-packaged libraries for things like sockets and RMI. Products: object databases (Ozone, the Castor O/R mapping framework), transaction managers (Tyrex), web servers (Resin, Jetty, Orion, Enhydra), XML etc.

Above all, Java connect to anything, provides a lot of freebies (garbage collection, a simple object model), is high-level and easy to learn, and lets you be more productive right out of the box as opposed to languages such as C++. No wonder new stuff is sprouting up like mushrooms -- a phenomenon that I suppose Bjarne Stroustrup is mildly annoyed about and doesn't quite understand. Once you've written a C++ app, it's a dead end. It not reusable. Unless you wired it up with magical strings and CORBA and reinventing all sorts of technologies, it just sits there.

This is much the same reason Python is thriving, really. Unfortunately, Java currently does not have anything that comes close to Zope. Turbine and Cocoon sound like two different projects aimed at this area, but they're not even close.

Who cares about Amex or set-top boxes? Unless I can write TiVo-like apps on my desktop computer that controls the box in interesting and hitherto-unrealized ways, it's useless, just another closed implementation. And Amex, well, how do I connect to my card, then?

Now:

• Both Oracle 8i and IBM's DB2 use Java extensively both for their DB administration GUIs as well as for middleware code. If you didn't know, these are the number 1 and number 2 Enterprise database systems in the world

I wish you hadn't mentioned that. Oracle's bloated, clunky Java GUI stuff is their big black sheep. I wish they never screwed this part up -- Oracle's native NT tools used to be at least adequate. Compare Oracle's present, slow, unstable, overdesigned, Microsoft Bob-like Java GUIs with Microsoft SQL Server 7.0's flashy, fast, and hugely functional tools and you just want to crawl into your mama's arms and cry like a baby.

• Java servlets and JSP are used extensively on the web from sites like mail.com to Firstunion.com. Hundreds of sites use Java(TM) to deliver dynamic content these two are simply the most prominent that come to mind.

Servlets is hardly Java's finest moment, same goes for JSP. True, servlets replace CGI in a nice way, and anything is better than ASP and assorted horrors, but that's about it.

Servlets make up a very low-level layer, and servlets themselves are quite isolated entities, compared to the riches of Zope's DTML documents.

Please, developers, do yourselves a favour and read up on how to properly divide content, logic, and presentation. Hint: Putting Java inside HTML gives you no cigar. Look instead at things like Freemarker and Webmacro, or even that bastard son of template processing, XSLT. Even so, these are quite weak tools, and you need to buy a $35,000-per-CPU app server to get any sense of an integrated package.

End of rant.

Three options I can think of are

1. Digital Creations' Zope
2. UserLand's Frontier.
3. Apple's WebObjects

Zope and Frontier are similar tools, giving you both very powerful behind-the-scenes scripting and database access and customizable easy-to-use frontends.

Frontier started as a scripting environment for the Macintosh, evolved into a great tool for designing complex static Web sites, and is now a full-blown HTTP server with very powerful database features. It's very XML-enabled (UserLand is active in the XML developer community, and is a co-author of SOAP). Manila gives you Web-based editing capabilities. See the EditThisPage Top 100 for some examples of what people are doing with Manila.

There are three main downsides to Frontier from my perspective that may not be an issue for your company:

1. It's expensive. US$899 per copy (basically per machine), with volume discounts for five or more licenses.
2. At the moment, it only runs on Windows (2000 and NT, of course, but also 95 and 98) and Macintosh. There is supposed to be a port to Linux underway, but the last time I heard anything, that port was going to be using WINE, and so would be x86-only.
3. It's proprietary. As a commercial product, the source is closed. It has a powerful scripting language called UserTalk that can allow you to do amazing things, but I don't know how easy it would be to write extensions.

Zope is a lot like Frontier, but free. It's written in Python, making it easier to write extensions, and is open source. It should run on any platform that can host a Python interpreter (Unix, Windows, Mac, for sure, but also BeOS and some others). The big downside to Zope is that it has virtually no useful ``getting started'' documentation right now (although an O'Reilly book is forthcoming). As a result, I suspect you'd have to do a fair amount of handholding to get people started.

WebObjects is a pretty high-end solution for building Web applications. It's been around for a while, and has a pretty good reputation, but it's definitely not for amateurs. It's now actually cheaper than Frontier (US$699 per copy). It runs on Mac OS X Server, Windows NT 4.0 and Windows 2000, Solaris 2.6 and 2.7, and HP-UX 11. (The development tools run on Mac OS X Server and Windows NT and 2000.) Programmable using Java, Objective C, or WebScript. WebObjects is definitely more oriented toward centralized control, and doesn't (by default) provide support for individual webmasters to run their own sites within its aegis.

I hope that gives you some ideas.

Anyone out there with an interest in InterBase and Zope should know that there is a nice, multi-threaded, Database Adapter for Zope called gvibDA.

Zope and InterBase make an awesome combination for building database backed websites.

Enjoy.

--Xar

Don't let the 0.1 version number scare you. It's quite usable.

Anyone out there with an interest in InterBase and Zope should know that there is a nice, multi-threaded, Database Adapter for Zope called gvibDA.

Zope and InterBase make an awesome combination for building database backed websites.

Enjoy.

--Xar

Don't let the 0.1 version number scare you. It's quite usable.

This is precisely why people approach VCs. If you're product's good and you believe in it, then you need capital to start the ball rolling and pay your in-house developers. This model only works if there's a market for support. Zope is a good example and is used on OpenSource.org's business person's case for open source. Paul Everitt of Digital Creations was told to go open source by their VC Verticality, and it looks like it's been a success. Everitt makes a very eloquent case for his open source business decision.

This is precisely why people approach VCs. If you're product's good and you believe in it, then you need capital to start the ball rolling and pay your in-house developers. This model only works if there's a market for support. Zope is a good example and is used on OpenSource.org's business person's case for open source. Paul Everitt of Digital Creations was told to go open source by their VC Verticality, and it looks like it's been a success. Everitt makes a very eloquent case for his open source business decision.

This is almost like the model Zope has (successfully) implemented. I am not sure how flexible your code is but you can look at some of the Zope case studies http://yyy.zope.org/Resources/CaseStudies and get a sense of specifically how this business model is effective.

The problem with PHP is that you start with a lot of HTML and a little code, which makes PHP seem perfect, but over time you wind up with lots of code that isn't organized at all because it's embedded in all your HTML pages, which makes the code very hard to maintain.

Perl, of course, has the opposite problem. You start with a simple database app with very little formatting, which makes a mod_perl script perfect for the job, but over time you start to add bells and whistles to the user interface until you again wind up with your code and HTML totally interspersed, which again makes maintenance very difficult.

You really need to have scripting on both sides (backend and display). The reason we define such a thing as "backend" is exactly so that we can reuse code. The display needs scripting, because reusable code doesn't output objects ready for display, because (by definition) ready for display is defined by the display.

I hadn't really thought about this duality much before, but now that I have I think I'll be more careful about how I make these distinctions.
--

There is a systems out, that does groupware type of functions through a browser.
It already exists, is open source, and is useable if not complete yet.
It can be found here.
It is called TWIG, or "The Web Information Gateway".
It might be a solution, and if more people got involved in it it might go faster, and get developed a bit more quickly.
There is also Zope.
It is a python programming language, and there are , I am sure, ways of duplicating Exchange to Outlook interaction using that.
Just my $.02

Zope is usually run as a long-running process that's accessed through either Persistent CGI or FastCGI (though the FastCGI was still unstable when I tried it). A FastCGI module is also available if you just want to run regular CGI scripts a bit faster, and mod_python is available as an Apache module.

Damn, 8 hours ago I submit a story about Perl Methods being added to Zope and about the release of mod_python 2.1 and it gets rejected??

What's wrong with Slashdot, ain't these the news for programmers? Another story by me which was also rejected was that Motif interview... and then 2 weeks pass and I finally read it on Slashdot.

I wonder how much do the Slashdot editors understand of programming. Why not showing the names of those who reject the stories? Anyway that was the last story I've sent.

Err... I for one always assumed that AOL's move to Linux will really just be a move to *Mozilla*, not another OS platform. People have to realize that Mozilla as it stands now is an *application platform*, as able (if not more so) than Java.

People can write whole Web-based applications in Mozilla. Look at Active State and Zope. AOL is smart enough to use this to their own advantage. Suddenly they got a version of AOL that can be deployed *over the network* to any PC or OS, w/o those pesky CDs. Added bonus: the main OS for testing this platform is (coincidentally, because of Netscape's incompetence) a *free* one, that they can do anything to.

Welcome back to the future: Mozilla is the VT100 of tomorrow :-)...



engineers never lie; we just approximate the truth.

I think you are confusing Zope with Midgard.

Zope uses Python as its underlying language. Midgard is the one that is built in PHP.

Both are worth a look, if only because they are Open Source and Free, so costing nothing.

Alex.

Alex.