-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Sep 30, 2007 at 06:03:33PM +0100, wouter van ooijen wrote:
> > Practically all commonly used protocols on the internet, at 
> > least the ones that use TCP as a transport, are line 
> > oriented, text based and human readable and writable. Is 
> > there an actual RFC (or similar standards document) 
> > describing this practice as a "best practice"?
> 
> I would not consider this a "best" practice (common: yes, best: no), and
> I am sure there are plenty protocols that don not follow this "line".
> (maybe: remote file systems? any other protocol that must pass data
> "transparent"?)

Actually, that touches on an issue that I'd be very interested to see a
good discussion of. There are a number of ways to pass data, http for
instance uses content-length headers or simply defining the end of the
data to be when the connection is closed. (over simplifying here...)
SMTP uses the a single .\n by itself as the end of the message, if the
message has a .\n in it, have ..\n instead. (although there is an
extension to simply pass stuff 8-bit clean, not quite sure the details 
there) In researching this I did find a site that talked about those 
various methods, but not in the context of a "universally" agreed upon 
best practices document.

Of course, in addition to that you get the design pattern of how so many
programs store xml now. The protocol/file format is plain old XML, which
is then wrapped in a compression format. OpenOffice's ODF for instance
is XML inside a ZIP format archive. (so images and the like can be in
their own files within the archive) Other formats simply put everything
in a gzip/bzip2 box. Compression technology is so good now that many
people report such approaches yield smaller files than a binary
format. The main problem with that approach is file
identification gets messed by, the file command (unix) reports the
wrapper rather than what's inside, but there may be better approaches
there too...

> But in most cases it does not harm either. If you want to aim your
> arrows target them to anyone who wants to spent time fussing over this.

My thoughts exactly...

> > The last time we met to integrate 
> > the two halves, he crypticly said there was a deep reason for 
> > the above that I, without 4 years of computer science, was 
> > never going to understand.
> 
> After 4 y CS, 14 y working in the field, a few years as an independent,
> and 4 y teaching I can't think of any reason why this would realy
> matter. If performance is the issue any ASCII endoing would be stupid.

Performence is definitely not it, messages will come down the line no
faster than a user can click a button. If anything, his approach is
going to be much more tricky to parse.

- -- 
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFG/8+E3bMhDbI9xWQRAnwdAKCFePoKPnl7TS+BWSFuQuoA9UGjfwCgpth2
jbUo4Xu1xwnasD1CegUaaJo=
=67TZ
-----END PGP SIGNATURE-----
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist