[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [JDEV] Well-formed XML.

This is all REALLY great stuff, and was my original intention to do it
this way when I first started long long ago...  it's the "right" way to do
it from many points of view :)

BUT, as I started implimenting the server(and learning C at the same time) 
it was MUCH easier to deal with the protocol the way it is now, and I'll
explain:  The server uses a main select() IO loop to handle the multiple
connections, and when there is data to read another function checks for
the <j></j> tags and extracts that packet, then hands it off to a general
handler routine which THEN passes that data to a (custom written) XML
parser, so the parser is just getting the data with one root element like
it expects....  So really, the protocol was adapted to make writing the
server easier at the time I started writing it.  And if you take the
approach to have a small handler roll around with the incoming data and
extract "packets" and hand them to the XML parser as it gets them, it
works quite well.

The "right" way to do it would be to just have the IO loop constantly
streaming data in chunks to an XML parser and change the protocol to look
more like a real XML document. I'd like to use expat to do this, but I
haven't looked into it enough yet to determine how it can deal with
incoming "chunks" of data...

The reason I haven't taken this step at any point yet is because it would
end up being an almost complete server rewrite, and although I'd REALLY
like to do that and do many things differenty/right, I just haven't had
enough TIME :)

To summarize, what we currently have "works" but could stand for a good
deal of improvement.  I announced/launched what I had in the state that it
is earlier this month so that I could hopefully find some help in doing
that "improvement".

<NOTE>
I'm going to do my best to write up a BIG STATUS UPDATE tonight
with all kinds of ideas and stuff on everything, from the server to the
protocol to the web site/docs and more...  hopefully help to bring
everyone to the same page and we can go from there
</NOTE>

Jer

On Thu, 21 Jan 1999, Jason Diamond wrote:

> Hi, I have another protocol related suggestion. I've been experimenting
> with a Java client and have been using several of the major XML parsers
> to test it out. Apparently, a well-formed XML document needs to have a
> single root element. Much like the root <html><!-- everything else goes
> here --></html> element in HTML. All of the parsers I've tried so far,
> stopped parsing at the second <j> element. There are several ugly
> workarounds but I think it would be much more conducive to our goals if
> we could take any off the shelf XML parser and not have to modify it in
> order to write a Jabber client. So, I propose that both the server and
> client wrap all their messages in a root <jabber></jabber> element.
> Attributes could be used to specify the client and protocol much like
> the current <j type='connection'> element. Maybe something like this:
> 
> <jabber agent='Jabzilla v1.0' protocol='19990121'>
>   <j type='login'><user>foo</user><pass>bar</pass></j>
>   <!-- etc. -->
> </jabber>
> 
> The end </jabber> element could be used to indicate that the server or
> client is getting ready to close the connection. Comments? I'm in the
> process of downloading Cygwin32 so that I can make the necessary changes
> to the server to test it out.
> 
> Just out of curiosity, why are all the messages between client and
> server wrapped in a <j type='foo'> element? Why not <login> or
> <message>? If we used element names rather than attribute types to
> distinguish the purpose of a message, we could create a DTD specifying
> what elements are allowed to be nested in others. For example, <user>
> and <pass> would only be allowed in a <login> element. I'm not proposing
> that we validate the XML as it comes in from the server, but it could be
> used as a specification. Much like EBNF is for more traditional
> protocols. And who knows, maybe while implementing and debugging our
> clients we could have it validate the XML as an aid to determine a
> source of errors.
> 
> Bye,
> Jason.
> 
>