My belated two cents... Andrew wrote:

1) Have an install that automatically installs a default webserver that will run as a background process

When ZServer gets out of beta and fully integrated, our story will be better on this. On many of your points I'm more in agreement with you than perhaps some of the other respondents, and this is one of them. Right now we have a bizarre process where you can run ZopeHTTPServer if you want to, but then shut it down to integrate it with Apache. But at that point you're screwed because your files in var are owned by the wrong person. And once you move to Apache (PCGI) you can't simultaneously have ZopeHTTPServer. With ZServer we'll get several usability enchancements: 1) Move away from process activation. The "magic" we have now where Apache starts up Zope is too much of a problem. It is too hard to tell what is happening, who owns what, did my app actually start, etc. 2) You can connect directly to Zope or through Apache simultaneously. 3) Obviously we'll get higher performance and integrated FTP...

2) have a feature rich install that has all the messaging, ftp, etc. packages pre-installed so users can just run it

I'd like to hear more about this.

3) an easier way to install new packages - like just clicking "install"

I agree with you on this point as well. It's too mysterious to find out what went wrong when, say, you have the wrong MySQL library. Also, you shouldn't have to restart the server when you add a new package. I don't yet know how to automate putting things in the Products directory. But once there, people should be able to go to the Control Panel and Add Product. If there is a problem, they'll see a message right away. Otherwise, they have the product installed without needing a reboot.

4) Port Zope to mac!!

Heh heh. None of us at DC have experience with C on the Mac. Is MacOS Server close enough? (Jeffrey just got that in the other day.)

5) Improve the admin interface with useful functions like "export site to HTML"

Amos and I have been talking about a number of alternatives on this one.

6) implement XML-RPC between two zope servers

Personally I think WebDAV between two servers is just as interesting. For instance, imagine a Zope Folder that was actually a proxy object for a remote WebDAV folder, perhaps being served by Apache. You navigate into it without realizing that it is making live (but possibly cached) requests to another Zope/Apache/IIS folder. If it is actually RPC that you want (running a function/method on another machine), that's different than sharing content.

7) implement a mailing list from within Zope

You got lots of responses on that so I won't pipe up. _Except_ to say that the value of a mailing list in the presence of the portal toolkit stuff we are doing for LinuxExpo goes up _dramatically_.

8) Product requests: a)web-board b)mailing list c)workflow d)project management

Again, well-travelled territory.

9) Create a "serialized" XML export/import format so that for example I could email a zope site to a friend as a single file and have them "import" it. Sans images of course.

Do you want them to import it into Zope or into non-Zope? The last would obviously only work for simple items (folders, images, files, etc.)

Questions 1) When will the next version of Zope be released?

Previously answered.

2) Could Zope use javascript sometime in the future? the JS reference implementation is open source as well, it could be incorporated...

I don't think this is as crazy a suggestion as others have indicated.

From an implementation standpoint it feels kind of weird. But from a pragmatic angle, there are _tons_ of books on JS, most editors (such as Dreamweaver, which I used for the first time this past weekend) grok it.

If we don't do JavaScript, we should at least do PythonScript on the server, where PythonScript is some mythical subset of the language that is considered "safe". DTML was never intended to scale up to, say, writing functions. But it is becoming increasingly clear to me that we need more powerful programming constructs that are actually stored in the database. --Paul