[Zope] Object Conversion (& GNOME, GUI, WebDAV support)

[Paul Everitt]

Ahh, a topic about which I have a lot of interest...

Eron Lloyd wrote:
> Is there a way to convert, say, a DTML Method into a DTML Document? By
> this, I mean only changing it's object-type property? Could I add a

I don't think it is as simple as that.  It's true that Zope objects have
a property "meta_type" that provides a label for the kind of thing they
are.  But they are all instances of a class.  DTML Methods are a
different class than DTML Documents.

Thus, you'd have to think in terms of destroying the old instance and
creating a new instance of a new class with the same id and data as the
old one.  I imagine this would have a lot of unintended side effects.

We've been thinking of re-uniting these two by making the Document vs.
Method "behavior" switchable without changing the class or the object id
(or the database object id).

> property to objects to allow their conversion, so the system would only
> look for those having this "switchable" property? Also, when I download
> a file using FTP or WebDAV, make changes, and then upload it back into
> Zope, where in the object is this property-type determined? A downloaded

Zope has a "magic" system like Unix and others that infers content type
from a number of parameters.  If the interaction is HTTP and
Content-Type is provided, that is used to map into object type.  If not,
file extensions are used.

This is definately an area ripe for improvement.  But it's a pretty hard
problem.

> DTML Method looks like a simple text object when viewed through a
> text-editor...what if when I uploaded it I wanted it to be a Document?
> Does Zope insert an ID that remains in the Database?
> 
> These questions are posed with thoughts of possibly coming up with a
> small GUI tool, that could be used as a sort of PyGNOME (or equivalent)
> content management that consisted of a Frontend to the Main.py Zope
> interface, where objects could be created and manipulated. XEmacs and
> FTP are ok for me, but for the content managers and users, a nice GUI
> tool would make Zope become adoptable easier. Also there is an idea to
> provide GNOME with WebDAV folders, since there really isn't much support
> for WebDAV under Linux thus far.

You're definately right on this.  A number of points...

First, if you have a rich programming environment, you'll have no
problems.  Why?  Because you control what method gets called when you
construct an object.  FTP doesn't know when to call
manage_addDTMLDocument or manage_addDTMLMethod.  You can use all the
power of the GUI and Python to collect or infer that decision.

Second, although I use Emacs a *lot* for editing Zope content lately, I
think its days are limited.  FTP isn't an object system.  I find myself
awfully constrained, particularly by the detail of not being able to
create a "News Item", but generally by the thunk in mindset.

Concerning GNOME and WebDAV.  I've spent some time corresponding with
Miguel, Nat, and some of the other GNOME guys about this.  GNOME is on
the way to a generic abstraction with Bonobo, but it isn't there yet.

The new file manager, the PIM, and many other GNOME application will
stop opening files directly and will start going through Bonobo to get
to them.  This is good because Bonobo handles the back-end
transparently.  "Files" might be on the local filesystem, a Samba
filesystem, an FTP server, etc.  Since Bonobo is a CORBA component
model, you get cross-language access.

Sound good?  Not so fast my friend.  Bonobo is still a file-oriented
component.  Meaning, the semantics of stat still prevail.  Want to do a
PROPFIND from WebDAV?  Bonobo will say, "We don't know no stinking
PROPFIND.  Files don't have no stinking properties."  This means that,
IMO, Bonobo isn't about accessing content-like objects, its about
accessing file-like object.

So you could jump in on the Bonobo list and (a) see if I've repeated it
incorrectly, and if so, (b) convince them to provide richer semantics. 
Without richer semantics, Bonobo will feel a whole lot like ange-ftp as
far as interacting with Zope.

This doesn't mean that you can't do the above.  You could create a GNOME
CORBA component that provided a much richer interface to managing
content.  I would *love* to see that.  There are probably a lot of
interesting interfaces and protocols that you could start with, such as
WebDAV or DOM.

You then implement your component in a way that it's easy to plug in new
front-end (e.g. WebDAV, XML-RPC) and back-end (e.g. Zope, filesystem,
Samba, Bonobo) architectures.

I imagine that, for someone that really knew PyGNOME and the GNOME
component model, constructing a prototype would be straightforward. 
However, for someone that *didn't* know the GNOME component model and
CORBA, it would be a long road indeed.

I have other interests in wanting to see this, beyond wanting a better
management environment for Zope.  The GNOME team is working on a
groupware application.  So far they have spent much of their time
thinking about the front end, but they don't really have a calenar
server, etc.  I think that, if they defined a good interface, Zope would
be a great platform.  I shudder to think they might store all that rich
content in MySQL.

--Paul