I'm on a far off rontinent, well out of reach of the smacking that I would
otherwise probably recieve for suggesting this. How hard would it be to
output XML to the socket, instead of HTML?? That way we do not incur the
ambiguities of HTML (does <H2>...</H2> mean the filename or its size??)
and we are not locked into a particular pickling routine. Which makes it
much easier for other apps to interoperate with circle.
What I don't understand is why people are more concerned with which
excessively abnoxious stamdard they're going to transport data in, rather
than what data actually needs to be transported. <HTML> is a nicity, I
presume, due to the fact that he was implementing that feature for the
express use in his CGI script. For real world purposes, a more generic
transport needs to be chosen -- something that was mentioned at the time.
XML just couches the information in an excessive number of tags. Keep the
message to the point, and encode it in the highest common denominator. A
number is a number. A word is a word. A string is a bunch of binary data
with some kind of end marker. What else is there? If you want to add tags
to allow more information to be passed in latter versions without breaking
the old stuff, then use "value=" pairs like everything. I can't see much
need for heirachial encoding of the data in the present structure. And if
it is needed, then I'd say there's something seriously wrong. We're getting
output from a command used to search for files, and then used again to
download one of them. It's not a hyper-document with thousands of other
documents and data base entries linked in.
XML encoding is pretty, and it gives the wankademics a hard on, but it's
also adding an unnecesary burdon on the client which has to deal with it.
I've always been an advocate of the KISS principle, especially in times like
this. A document that's got to be read on different architectures, with
different encodings, and so forth... Fine. XML is wonderful. But the
CircleD <-> Circle/client interface is all going to be within a single
architecture, on a single machine (otherwise we may as well do away with
this idea all together). It doesn't need all the extras offered by XML.
About the only thing XML does offer that isn't just as easy to do by other
means, is a safe encoding of the strings. But in our limited environment,
that can be garanteed without the overhead of XML parsers and so forth.
Perhaps that's juts me and my assembler upbringing. But I tend to believe
that more features is far better than more complexity.
Steven (aka Zaphod)