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

Re: [JDEV] Well-formed XML.

I haven't actually written an application using Expat but have looked into it.
It works differently than the Java parsers I am familiar with. You have to
feed Expat chunks of data to parse. The parse function takes a boolean
parameter called isFinal that you set to true when you pass the final chunk of
the document. I think that's exactly what we need. It's actually a lot more
intuitive (from my point of view) than the SAX interfaces I have been using in
Java.

I'm looking foward to the status update tonight. I'd love to offer help in
whatever area needs it. See you then.

Jason.

Jeremie wrote:

> 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.
> >
> >