Comments on new Message code.

[gd...@macromedia.com]

OK, I started off making a bunch of very detailed comments about the code,
but I think it's a better tack to discuss things at a higher level.

* First off, it appears each message now has a single MessageElementRecorder
which records the entire SAX stream for the message.  I don't like this
change, here's why - with the current model, you can parse/deserialize the
SAX stream in realtime into some much more compact representation, or even
skip things entirely if you aren't going to need them.  Also, it's easy to
create subclasses of Header, for instance, that have custom attributes that
get read and set at creation-time instead of having to build adapters to get
them (see DebugHeader in the current CVS).

* I realize this isn't finished yet, but there's no connection between the
parser and the get*Elements() functions of the Message.  This means
getHeaderElements() doesn't trigger a parse, nor is support for incremental
parsing anywhere in here, so you need to parse the whole thing into memory
at the get-go.  This blows away the "parse the headers, but not the body"
pattern...?

* There's no programmatic envelope/element creation in this code yet, nor do
I see any type mapping stuff.

* MessageElementAdapters seem very much like the Deserializers which are
already in the current codebase, except that everything here seems to rely
on having the SAX events around.

* I don't see how a message might move through the system without being
parsed.  For instance, I'd like to be able to write Handlers that leave the
message as an InputStream all the way through the system - let's say I'm an
intermediary who only cares about inserting a header into the Response
message from a remote server.  I just want to forward the incoming message
directly to the next guy, so no parsing should be necessary.

(There's a few other things but those are the main ones.)

Summary : I don't really see what we're gaining from these changes.  It
seems like there's still quite a lot of work to put in to get this code as
functional as what's there now, so why not just try and make the changes
that make sense to the current codebase, rather than doing a big rewrite?
James, could you explain the problems you have with the current code and why
you think this is necessary work?  I'm willing to go with this if there are
good reasons, but I need to know why it's a good use of energy and time.

What do others think?

--Glen

Glen Daniels
Macromedia
Engineering Manager
http://www.macromedia.com/
                                Building cool stuff for web developers