Re: Fwd: LOPT: serialization algorithm suggestions

On Tue, Apr 18, 2000 at 08:20:23AM -0500, Ken MacLeod wrote:
> "Eric Prud'hommeaux" <eric@w3.org> writes:
> 
> > I had imagined that the object serializing the data would be
> > hard-coded to the structure, and that the generality of expression
> > would payoff when a generic receiving agent was able to construct
> > the data objects to pass to a handler. The handler would know that
> > the memory image it was passed was actually a t_Bar and say:
> > 
> > LOTPResult LOTP_Bar_Handler (LOTPContext * c, int argc, void * argv[]) {
> >     t_Bar * myBar = (t_Bar *)argv[0];
> >     LOTPDeferred * reply = new LOTPDeferred("I'll get back to you.");
> >     return reply;
> > }
> 
> This is the crux of the problem.  Without some form of validation of
> the XML input structure, your C code is going to dereference a pointer
> and likely core dump if somebody passed you something you didn't

I'm not proposing that everyone use it or allow it. An aparatus to
communicate structure could just be used between trusted apps. Or it
could just core; the supplier of the bad structure could interpret the
dropped connection as negative feedback. There are plenty of ways to
get COM to barf, yet it is useful between apps that know what they are
doing.

One could argue that that apps that know what they are doing could use
their own serialization format, but I think that there are great
uniformity and reuse paybacks if the XML-protocol serialization format
is also usefull for structure transfers and DB transfers, etc.

> expect.  As soon as you add in the code necessary to do validation of
> the XML input structure you have enough information to distinguish
> pointers and nested data and the serialization format no longer needs
> the extra complexity (attributes) to distinguish them.

I think data validatation is as hard as the classic halting problem.
You have to be able to prove the data is internally consistent (not so
hard) and consistent in the context of everything else the program
sees (including bugs). Internal consistancy helps you deal gracefully
with a lot of potential errors, but whether or not you limit yourself
to serializing references, there will be plenty of programs that can
be caused to core given bad data.

-- 
-eric

(eric@w3.org)

Received on Wednesday, 19 April 2000 09:12:58 UTC