[Zope] Feature requests and questions

[Paul Everitt]

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