LD Landis wrote:
<SOAPBOX> "Languages" that do not have a 'external' representation really "get my goat". There is no reason to not have a "source code" representation for anything that appears in a symbol table (e.g. the 'internal object structure').
I want source1->encode->structure->decode->source2 such that if I apply the above to my source creating source1, and then apply it again to source1 resulting in source2, source1 and source2 are character identicial (comments and all), and except for use of "white space" both source1 and source2 are character identical to my original source. (Like I can do with indent(1) to enforce a 'shop coding style standard'). </SOAPBOX>
Two observations: 1) Does the XML Export accomplish roughly what you want? Namely, a mostly-text representation that can be round-tripped. 2) What do you do when your source can also have state? That is, your source is stored as a rich object in a database, and can have run-time settings (permissions, properties, etc.). Uou are asking for both your source *and* your database to exhibit the above. Thus, can you name a database system that doesn't "get your goat"?
In reading Paul's reply, I am reminded of what /proc does... (To my knowledge) nothing in /proc is a "real" file, but open(), read() etc don't seem to notice that. Likewise, the "source" interface to ZOPE could have an ftp (or even 'mountable filesystem') "appearance" for the
I'd love for someone to write a mountable filesystem for Zope, but I'm not sure how much it would help. Zope has a lot of semantics that stat doesn't cover. The problem here isn't how to get the object. The problem is how to express the object once it is gotten in a way that old-style, file-oriented programs and protocols (e.g. Emacs and ftp) can still participate. The problem, and the goat :^), are as much with all the editors in the world and their protocols as it is with Zope. I could easily change your goat to say "All editors and IDEs should work with the web object model." :^)
navigational/organizational aspects (object hierarchy). The contents of each object (IMO) *must* have a source code representation, which is fully
Again, do you make the same demand of Oracle/MySQL? If so, how do they accomplish it?
capable of representing all aspects of the object, but in a "conventional" format (not XML).
Please name the format you're thinking of. If you ask nearly anyone on this list, "Name the standard for clear-text encoding of dynamic content", I imagine XML would get the most votes. I personally can't think of many other choices. Perhaps we could use the Python text-based pickle format. :^)
The fact that XML is capable of representing everything in ZOPE, it seems that a suitable set of DTD/mapping/magic would render (decode) any ZOPE object into a 'suitable' (<retronym>human</retronym> language independent) source code, and could drive a "compiler" that would translate (encode) a source back into the internal object structure.
Are you suggesting we use an existing language and parser, or invent a new one? If the former, which one?
Essentially, what I am suggesting would be to add a layer between people and the existing XML interface, where there is a 1:1 relationship between each "source code construct" and each "object structure construct".
ftp | /--->Encoder-->\ fs |Source- | --XML--ZOPE etc | Code \<---Decoder<--/ \ DTD/mapping/magic (vulgar localizations)
XML is that layer. Whatever you've invented would replace XML, which would serve no purpose in the above diagram.
In fact, this interface notion would be useful regardless of the "source" code, even XML. Maybe I am missing something, but it seems to me that the XML encode/decode interface is mostly (if not completely) done. The questions that I have are:
1. How well does the import/export function deal with 'partial' trees
It seems to me that this is important for working on a single ZOPE instance, or collection of instances, irrespective of the hierarchy from which they may have been selected.
It handles it, I believe.
2. Can the acquisition expectations (of an object) be stated, or explicitly encoded so that the encoding of an object more or less 'stands alone' (that is, acquisition expectations be identified by name so that any willing supplier of that name is acceptable.
This is probably currently a weak link because (from what I've seen, the XML representation is accomplishing the encoding of these dependencies by "nesting" the specs. IMO, the dependencies need to have explicit encoding rather than a "inclusive scoping" (akin to what we have in explicit transistors vs nested gates, or explicit gates vs nested chips, in a circuit).
Hmm, perhaps you could make a specific proposal? The design goal of acquisition was to make it transparent. If instead we take it in a direction where people have to use different syntax, and know it is there, then that would take it out of the hands of non-programmers. In summary, I think it is doubtful that you could invent a language that would improve on XML and gain wide acceptance. Perhaps it's worth a shot, so the best I can say is, good luck! --Paul