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).


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 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<> 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

Reply via email to