[JDEV] Re: server2client

Chris behmc at alleg.edu
Mon Sep 20 11:25:37 CDT 1999


On Monday, September 20, 1999 at 12:11 PM, belg4mit at MIT.EDU wrote:

> >Then the client goofed, the messages come in as <message></message>.
> >I'm working on the mac client right now, and you watch for the ending
> >message tag. At that point you know you've gotten one whole message.
> >I read the data and send it to the XML parser (expat). When expat
> >sees an end tag, an end tag handler is called. AFAIK there isn't
> >really a _need_ for a carriage return EOM marker.
> I think you did not understand what I said, for this is exactly my
> point.
> 
> given an instaneous stream of:
> <message>
>   <!-- crap -->
> </message>
> <message>
>   <!-- other crap -->
> </message>
> 
> The client has to know XML itself (or it's supporting lib) to know
> that that is two messages?

Yes, the clients have to know XML. The whole protocol is based off of
XML so it kinda makes sense that the clients have to know it...

> <!-- keep in the mind iscoming from a perl view --> This would mean
> you'd have to read a single byte at a time to prevent getting
> extraneous data. (you could read more and do some funky stuff to save
> it of course) This seems to be a very uncool manner of doing things.
> Why wasn't a length attrib added to the message tag? the length being
> from the > at then end of the <message tag> to the > of the </message>
> tag. Yes I realize this mean's the whole message must be known before
> it can be streamed, but it seems a small price to play for sanity.

There is no such problem with reading a single byte at a time. I read
whatever I get from the server and send it to expat. Expat deals with
what it gets. When it sees that first </message> it has gotten a
<message> before it (heh, at least it better have) and the data in
between has stored in confusing structures that I can use, but don't
understand fully ;) That </message> causes expat to call the end element
handler, which is where I take a look at the tag.

At the "topmost" level, I look for the "major" tags, like roster. Then
those go to the handler for that type of tag. Those handlers know about
types of tags that can be inside their enclosing tag.

If you were to write an XML parser yourself I imagine it would be no fun
at all, but expat works very well. It handles the messy stuff.

--
Chris
ICQ#4957571
--






More information about the JDev mailing list