Re: [Zope-dev] FTP interface being worked on?
Chris McDonough <chrism@digicool.com> writes:
I think the only good reasons we have right now for having filesystem-compatible serialization are to make Zope content editable via common tools in a way that makes sense to people not used to (or comfortable with) the object database, and to give people a plausible way to put a Zope site under source control.
Are you thinking that we would build client-side tools to recognize an XML representation of a subpart of a site?
Client-side tools, no. I'm thinking that exporting to XML would allow existing tools to recognize and manipulate a subpart of a site. I'm basically agreeing with you - "common tools" for manipulating text sounds like parsers to me. I'm not sure why XML is considered less readable than an unknown format for Zope object serialization; I guess I haven't seen what's being considered. But it seems to me that for humans, XML might lose by a little, but for any type of mediated or batch processing, XML wins by a lot. Parsers are standard enough that their APIs are easy to learn if you've played with them before. Random human-editable text formats sounds like StructuredText; when I think of StructuredText I think "simple DOM serialization". Is there a particular set of tools or editing paradigms that we have in mind when we say that a non-XML representation is suited for client side tools? This is the way that Manila seems to be doing it: http://www.thetwowayweb.com/theXmlFiles -- Karl Anderson karl@digicool.com
Are you thinking that we would build client-side tools to recognize an XML representation of a subpart of a site?
Client-side tools, no. I'm thinking that exporting to XML would allow existing tools to recognize and manipulate a subpart of a site.
Which ones?
I'm basically agreeing with you - "common tools" for manipulating text sounds like parsers to me.
I'm not sure why XML is considered less readable than an unknown format for Zope object serialization; I guess I haven't seen what's being considered. But it seems to me that for humans, XML might lose by a little, but for any type of mediated or batch processing, XML wins by a lot. Parsers are standard enough that their APIs are easy to learn if you've played with them before.
XML doesn't play with diff very well... additionally, XML isn't as easy to work with as what I think it should look like. For example, I'd rather serialize a PythonScript into: def foo(self): print "hi!" than... <?xml version="1.0"?> <pythonscript> <function> <functiondef name="foo"> <arg>self</arg> </functiondef> <functionbody> print "hi!" </functionbody> </function> </pythonscript> The former is easier to understand.
Is there a particular set of tools or editing paradigms that we have in mind when we say that a non-XML representation is suited for client side tools?
Yes.. anything that works well with diff and CVS and is recognizable by a human. PythonScripts should be serialized to something that looks like a regular Python script. Images should look like images, etc. The directory tree generated should look as much as possible like a normal filesystem. I can see a middle ground that's more parser-friendly, but it's sorta a different goal AFAICT. An XML rep might let you use something like XSLT to do some transformation across all the representations of the objects that a more human-friendly representation wouldn't, but it would lose lots of other utility which I think is more aligned with the goals of the proposal I put up... that's not to say that a middle-ground XML representation somewhere between "ppml" (XML export format) and human-friendly isn't something that's desirable for lots of folks, it's just not what the proposal was about.
On 26 Mar 2001, Karl Anderson wrote:
Is there a particular set of tools or editing paradigms that we have in mind when we say that a non-XML representation is suited for client side tools?
I think the prime current example of this is the way you can use any text editor to edit the serialized format of a pythonscript: metadata is included in the serialized format as header lines. The fact that this is *very* pythonscript specific is the motivation for a class-implemented serialization format, IMO. When possible, the metadata *ought* to go in the same file as the body, simply because it makes the human edit cycle more convenient/faster, thus raising productivity. Again, I'm focusing on "editing via arbitrary external text editing tools" here, and not CVS, but if the conversion is invariant, it works for CVS too. --RDM
participants (3)
-
Chris McDonough -
Karl Anderson -
R. David Murray