Re: java serialization alternative

> Well, I wouldn't recommend using a *crappy* XML-based framework. :-)
> Saying that some XML frameworks are crappy and opaque isn't a good
> counterargument--some are decent.
>
But the argument that objects and XML have every bit as much of an impedance
mismatch as objects and SQL do *is* a good counterargument. If you want nice
Infoset-friendly XML, your object model has to be built to accommodate that.
If you want a nice domain-object-friendly API, then your XML is going to
suffer. If you want to try and serve both masters, you're going to be caught
between a rock and a hard place for a really long time.

> I love binary, but plain text protocols are typically easier to work
> with (see Pragmatic Programmer). "Relatively easy" is relative. It's
> actually impossible to reverse some parts of a serialization stream
> automatically (namely the optional data--all you can get is a stream
> of objects mixed with opaque chunks of bytes). Serialization embeds
> some of the structural information directly in the stream with every
> piece of data (talk about inefficient), and you're supposed to
> document the remaining parts in Javadoc (not very tool friendly).
> 
Plain text formats are good for certain things, and binary formats are good
for other things. A lot of it has to do with the context surrounding the
protocol; does it need to proxy, cache, and some of the other architectural
forces that went into REST? Then text works well, granted. And there's no
reason why a hybrid text/binary format can't carry the day here, either, a
la HTTP. But trying to force everything into a plain-text format is dogma,
and all dogma is evil; even Dave and Andy would agree with that, and you
know it. ;-)

> I'd just assume keep the structural information all together on its
> own and enable powerful tooling and efficient data.
>
Except that text formats--and XML--can be more INefficient at carrying
certain kinds of data, and you know that, too. Just look at
SOAP-with-Attachments or MTOM to see the pain. :-)

I'm not arguing that binary formats are "always better"; I'm arguing that
plain text formats are NOT "always better".

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
 

> -----Original Message-----
> From: Discussion of advanced Java topics. [mailto:ADVANCED-
> [email protected]] On Behalf Of Bob Lee
> Sent: Friday, April 04, 2008 9:56 AM
> To: [email protected]
> Subject: Re: [ADVANCED-JAVA] java serialization alternative
> 
> 2008/4/4 Ted Neward <[email protected]>:
> >  Um.... No. Just because it's in XML doesn't mean it's readable--
> after all,
> >  have you *seen* what a .NET DataSet turns into when it's serialized?
> >  *shudder* Don't even TRY to go at this with XPath. Ditto for the
> original
> >  SOAP (0.25 version) formats. Angle brackets do NOT make everything
> better.
> 
> Well, I wouldn't recommend using a *crappy* XML-based framework. :-)
> Saying that some XML frameworks are crappy and opaque isn't a good
> counterargument--some are decent.
> 
> >  The serialization format is well-known, and relatively easy to
> reverse
> >  directly from binary if you want/need to. Just because it's binary
> doesn't
> >  mean it's bad.
> 
> I love binary, but plain text protocols are typically easier to work
> with (see Pragmatic Programmer). "Relatively easy" is relative. It's
> actually impossible to reverse some parts of a serialization stream
> automatically (namely the optional data--all you can get is a stream
> of objects mixed with opaque chunks of bytes). Serialization embeds
> some of the structural information directly in the stream with every
> piece of data (talk about inefficient), and you're supposed to
> document the remaining parts in Javadoc (not very tool friendly).
> 
> I'd just assume keep the structural information all together on its
> own and enable powerful tooling and efficient data.
> 
> >  Arguing for Cloneable in its Java 1.0 incarnation form, you're
> right.
> >  Arguing for a marker interface that extracts "cloneability" into a
> separate
> >  concern, that would seem to be a good thing, to me.
> 
> Right. I'm arguing against an implementation, not a concept, and for a
> better concept.
> 
> Bob
> 
> ===================================
> This list is hosted by DevelopMentor®  http://www.develop.com
> 
> View archives and manage your subscription(s) at
> http://discuss.develop.com
> 
> No virus found in this incoming message.
> Checked by AVG.
> Version: 7.5.519 / Virus Database: 269.22.5/1359 - Release Date:
> 4/4/2008 8:23 AM
> 

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.519 / Virus Database: 269.22.5/1359 - Release Date: 4/4/2008
8:23 AM
 

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com