[Zope3-dev] Proposal for file-system synchronization in Zope3

[Jim Fulton]

Andy McKay wrote:
> There are two issues here: synchronization and serving.
> 
> If we dont want to discuss the issue of serving content from the file system
> thats fine, lets leave that out for now, its a whole other discussion.

The file-system synchromization is absolutely not about serving from the
file system. It isn't about that now and it never will be.

What it *is* about is allowing you to use file-system tools, including
revision control systems, to work with objects, especially software.


> But lets take a look at File Directory Views that are in the CMF. They allow
> me to write a Script Python object on the file system. I can then write
> properties and security for that object by making .properties and .security
> files. Whilst the object remains on the file system, it can be served from
> Zope. This product then allows you to "customise" the object and lo and
> behold an object is created inside Zope. I've syncrohnised from the File
> System to Zope.

No, this is not synchronization. You have made a new object whan you customize.

> Its a relatively trivial script to do the reverse for example
> (http://www.zope.org/Members/andym/zodb2fs).

It's not as trivial as you suggest. The script only works for a few content types.
It doesn't handle folder properties and makes a lot of assumptions about the
data schemas of the objects it does handle. It doesn't handle merging
file-system and database changes,


 > However these two systems
> generate files that are incompatible with each other. Sounds like I have a
> very similar system now to Jim's.

Not really.


 > If the File Directory Views from the CMF
> are broken would some time being spent on improving those be better?

No, because the goals *are* different. File directory views are about serving,
not synchronization. They, like your script, only handle a few object types.
They don't provide a framework for extensibility.

 > How
> does this proposal help CMF?

It could help CMF by, for example, allowing customized scripts to be synchonized.
In fact, it would eliminate the need for file-directory views, allowing a choice
of how one wants to manage their data.


> How about exporting and importing? When I export an object I get a "lossless
> file system representation" of the object. It happens to be in binary or xml
> format, that is harder to edit, diff etc.  Would this system be another
> option for exporting / importing a file?

Possibly.

 > There are a few minor differences
> there, but I don't see why the two couldnt be integrated: export as xml /
> zexp or "editable object". I suppose the only big difference is that when
> you import an object it replaces rather than changes an existing object.

With the file-system synchronization model, you could have a choice of
creating a new object or replacing an old one.

I have to say that I really don't understand what your complaint is.
Can you say what specifically ypu would like to be different?  Are
you trying to suggest that existing systems could be leveraged? If so,
could you be more specific?

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org