As a former WebObjects programmer and NextStep fan, I like the non-xml plist format. Its dead simple but very powerful.
dictionary is { key1 = value1; key2 = value2; key3 = "Some text on\ntwo lines."; } list/array is ( one, two, "Complex string" ) or its a string. Any nesting of the above is possible - you can create oids if you like to do cross linking but the basic plist format is very powerful and you can do a parser in a few lines of code. I use it constantly from java :-( these days.
-----Original Message----- From: Cees de Groot [mailto:cg@cdegroot.com] Sent: Tuesday, April 30, 2002 11:28 AM To: squeak-dev@lists.squeakfoundation.org Subject: Re: Alan Kay in the News
Mark S. Miller markm@caplet.com said:
So don't be shy about proposing Squeak-based or Parcels-based
serialization
formats.
Braindump:
- SRP (State Replication Protocol) is a Smalltalk-platform-neutral protocol with some nice properties, and is expressly meant to be usable on platforms besides Smalltalk. Especially the data encoding is cool, but apart from that it also has good support for class evolution, etcetera. http://wiki.cs.uiuc.edu/CampSmalltalk/About+State+Replication+Protocol+( SRP)
- Python has a neat serialization format that is based on some sort of mini-language which has textual and binary representations, support for custom formats and things like oid-replacements. Jim Fulton (Zope and formerly Smalltalk) thinks it is usable from other languages as well. The pickle.py module is less than 1000 lines of code.
- I wouldn't suggest XML - all the code doing the XML parsing is probably too large for anything security-related.
- RMI would be doable in Smalltalk, I think; it's well specified and the people behind RMI know what they were talking about so IMHO it's an OK wire protocol. The multiplexing makes it quite efficient from a resource-usage point of view. As you remark, Java serialization is a tad complex, so this might be a big job. http://java.sun.com/products/jdk/1.1/docs/guide/rmi/spec/rmi-protocol.do c.html http://java.sun.com/products/jdk/1.2/docs/guide/serialization/spec/seria lTOC.doc.html
- The Parcel format is VisualWorks specific, although it probably could be ported (the problem is that the format has no formal specification AFAIK, so a 'port' would almost certainly mean having to read code from VisualWorks, which brings you in muddy legal waters).
Even though I haven't followed the conversation on the E list on the necessity of a text format, I dissent. I think that if you want a human to talk to a running E instance through telnet you would better open a separate connection with a minimal command language (maybe one that would allow you to specify an object, step by step, and then you enter the "send" command).
- The format must be compatible with our security requirements. In
particular, since E is only prepared to trust mobile E code, any need
for
executable code in the serialization format must be E code. Parcels as
is
fails this test of course.
In the context of heterogenous E implementations, the point of mobile code becomes tricky, of course :-)
squeak-dev@lists.squeakfoundation.org