[XML-SIG] WDDX for Python

[Simeon Simeonov]

Hi, Paul!

It's good to hear from you. My comments are intersperced below:


>I'm not entirely happy with the logical level of WDDX. My problem is I
>can't easily understand when I would use WDDX.

Think of WDDX as the epitome of the 80/20 rule. It tries to provide a
solution for 80% of the meaningful data exchange problems with 20% of the
effort. The 80% that WDDX focuses on involve the easy and efficient exchange
of complex structured _data_ (not objects) between different language
platforms. So far, WDDX can be used with C++, Java, COM (VBScript, ASP,
Delphi, PowerBuilder, etc.), ColdFusion, JavaScript, and Perl. WDDX is
particularly well-suited for use on the Web because its XML data format can
be easily transported over HTTP.

Example apps:

- At Allaire we use WDDX to exchange data between the ColdFusion Application
Server and the ColdFusion Studio remote debugger.

- Some big public ecommerce and content providers are working on
WDDX-enabling their sites to expose data for application use.

- Try this URL for another cool example of WDDX use:
http://forums.allaire.com/Forums/Index.cfm?CFApp=49&Message_ID=225377

>Information passing situations seem to fall under two wide categories.
>Either we have a negotiated format (i.e. packet template) or we do not.
>
>If we DO, then why do we want to tag things <STRING>...</STRING>,
><NUMBER>...</NUMBER> etc. Can't we infer the types of things from our
>pre-negotiated template?
>

I agree. We fall in the latter category.

>If we DO NOT, then wouldn't it be useful to be able to linearize objects
>of *named types* instead of only primitive types? i.e.
>
><OBJECT TYPE="Traceback">
>  <VAR ...>
>  <VAR ...>
>  <VAR ...>
>  <VAR ...>
></OBJECT>
>
>Using the TYPE attribute, we could look up the constuctor for the
>appropriate type and invoke it. The problem is that Python programmers
>seldom work with data structures made of primitive and compound types.
>Rather they work with structures of objects.

When you want to reach such a wide audience you have to make concessions. In
particular, we had to decide that we couldn't exchange objects because some
of the target languages have no notion of such.

>If you can't encode and
>decode those easily then you haven't made the job of encoding data
>structures much easier.

I would disagree with you here... How can a Python app exchange data with an
ecommerce app written in ColdFusion? Or a book browser that's written in
Perl? Or with Microsoft Word? How can it send a recordset and a three
dimensional array to a web browser where these data can be used to build
cool DHTML UI?

The core problem of cross-language data exchange is very difficult. WDDX
offers you one way to talk to a _huge_ audience of applications. It is not
perfect, but it is far better than the "roll-your-own" approach.

>We could encode objects as structs, but then their type gets lost so that
>they cannot be rebuilt "on the other end."

This is correct. It will be easy to work with objects in Python and encode
them as structs using something like the dynamic serialization shown by the
JavaScript serializer.

And, yes, it is not easy to wrap objects around the data returned by a
deserializer. Probably the easiest way to do this is to build an object
factory for particular types of WDDX packets and apply it on the result of
the deserialization. Whether this will be worth doing depends on your
application.

>Maybe you could help me to understand a typical usage situation.

Bottom line: WDDX is not a solution for python-python object serialization.
It can, however, open python apps up and let them communicate with a _huge_
number of other applications.

Hope this help. Stay in touch.

Regards,

Sim
Allaire