Let me add that both Ruby and Python have implemented YAML as (one of) their data marsalling protocols. It has several advantages (to me) over other protocols and I believe should be (one of) the first choice(s) for ooRexx. For those who haven't looked at it, it is a sequence of strings that can be easily "read" by humans as well as unmarshalled back into the original object. Brandon Cherry has an implementation of the JSON protocol (in the incubator?) which is a subset of YAML so we have a bit of a precedent as well. Here is a link to the YAML site - http://www.yaml.org/ - and the latest (yesterday) spec - http://www.yaml.org/spec/1.2/spec.html - for anyone wanting to investigate the protocol further.
Rony G. Flatscher wrote: > Remote invocation has always to deal with how to marshall and unmarshall > argument and return values in order to transport the values insulated > from operating system and hardware architecture dependencies. In their > origins a lot of those infrastructures (including programming language > representations of values) were influencing the kind of un/marshalling > of values, including means that were proprietary, locking out others. > Hence using a string-based encoding, that may be even self-documentary > would assert that un/marshalling remained open. Using XML as such a > format may make sense for that purpose and could probably also be used > for serializing/deserializing ooRexx objects in general (ultimately, if > enough information gets serialized, even full fledged classes with their > methods could be serialized and deserialized in the end). > > ---rony > > P.S.: One nice application of XML encoded (serialized?) information in > the context of ooRexx would be a "rexxc" kind of program that would > encode the parse results of any ooRexx program in XML (tagging > statements, variables, operations, directives etc.), opening up > processing and analysis of ooRexx programs to any ooRexx programmer (who > could create xrefs, transformations, analysis of code et.al) who is able > to (conceptually) work with XML and/or XSLT. [Actually, even > observer/visitor pattern kind of infrastructure in the parser would be > "cool" and quite helpful for the purpose of analyzing and/or > transforming ooRexx programs.] > > > > Rick McGuire wrote: > >>Yes, but in those cases, XML is just the protocol used for >>serializing/deserializing the data. In most web services stacks, for >>example, the programmer just deals with real objects in the languages >>they're programming in and the fact that XML is used for the remote >>transport protocol is completely hidden from view. Done correctly, >>the transport protcols could be XML/Soap, REST, CORBA, RMIIIOP, and >>the programmer would need to know the difference. In none of those >>cases is the data being sent back and forth considered to be "just >>strings". >> >>Rick >> >>On Wed, Jul 22, 2009 at 3:13 AM, Mike Cowlishaw<m...@uk.ibm.com> wrote: >> >> >>>>Up until the point where you wish to pass an array as an argument or >>>>have a return value that is some sort of non-string type. Not >>>>everything maps well to just string data. >>>> >>> >>>Hmmm, try telling that to an XML fanatic :-)) Just about anything can be >>>moved around using XML -- which is just strings... >>> >>>Mike >>> >>> > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > -- Gil Barmwater ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
