[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [JDEV] Well-formed XML.
Very nice. My workaround used the same hack but was nowhere near as pretty.
Would this be as easy in other languages like C? I imagine that's what most of
the clients will be written in.
I patched the server to use <jabber></jabber> as a root element and
everything's parsing fine now.
If the protocol did require the root element, it might actually resemble any
other XML document. Maybe clients can log every message from their servers for
a sort of recording of a session. You can playback the log like you were
watching a movie.
Anyways, I'm gonna to get back to work.
Jason.
qbradley@csc.UVic.CA wrote:
> One hackish solution to this problem in Java is to create a custom
> InputStream like this:
>
> public class JabberInputStream extends InputStream
> {
> InputStream inputs[];
> InputStream current;
> int index;
>
> InputStream input;
>
> public JabberInputStream(InputStream input)
> {
> this.input = input;
> inputs = new InputStream[3];
> inputs[0] = new StringBufferInputStream("<jabber>");
> inputs[1] = input;
> inputs[2] = new StringBufferInputStream("</jabber>");
> index = 0;
> current = inputs[index];
> }
>
> public void close() throws IOException { input.close(); }
> public int read() throws IOException
> {
> try {
> return current.read();
> } catch (EOFException eofe) {
> if (index >= inputs.length) throw eofe
> index++;
> current = inputs[index];
> return current.read();
> }
> }
> }
>
> By passing the above class to the XML parsing library, it will basically
> wrap the <jabber> .. </jabber> tags around whatever was originally going
> to be there.
>
> However, I agree it would be really nice if the protocol required an
> entire connection to be wrapped in a surrounding tag.
>
> 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.
> >
> >
> >
>
> Quetzalcoatl Bradley
> qbradley@csc.uvic.ca