[gopher] Blocks: building and parsing them.

["William G. Davis" <william_gordon_davis@xxxxxxxxx>]

I came to the conclusion not long ago that Gopher+
attribute information blocks are fundamentally flawed.
I realized this when I attempted to write a block
parser for Net::Gopher. I figured that?like HTTP
headers?they'd be incredibly simple to parse. How
about a tree? A hash of block names and values...
Maybe a hash of hashes with block names, values, and
then attribute names and values within them?

From an API standpoint, any interface I attempted to
devise was confronted with several problems:

1) It's not enough to just give the programmer the
ability to retrieve block values because each block
value requires additional parsing;

2) the additional parsing is complicated by the fact
that the format of each block value is substantial
different from one another;

3) and even though these formats are simple (tab
delimited fields, "Name: value" pairs), when combined,
they become complicated and end up requiring several
different parsers to get the job done instead of one.



The tree approach really didn't work to well. Using
every single trick up Perl's sleeve (including the
"overload" pragma) couldn't make it elegant.

I find it so surprising that this situation came to be
even though Mark et al. actually ate their own dog
food: they wrote and maintained a Gopher+ client that
juggled information blocks, and yet it apparently
never occurred to them to make things simpler?much
simpler.

I think it would have been better if the format of
each block value had been identical. I see at least
two ways this could have been done in a reasonable,
flexible manor: 1) "+NAME: value" pairs with "Name:
value" pairs inside of them, or 2) "+NAME: value"
pairs with tab-delimited fields inside of them:

+INFO
 Type: 0
 Display: Archived Report (2003)
 Selector: /03report
 Host: gopher.somehost.comic
 Port: 70
 Gopher+: +
+ADMIN
 Name: John Jones
 Email: jjones@somehost.comic
+DATE:
 Created: 20030907153604
 Modified: 20030907153604
 Expires: 20050101000001
+VIEW
 Format: text/plain
 Language: en/us
 Size: 10567
+VIEW
 Format: text/html
 Language: en/us
 Size: 12043
+VIEW
 Format: application/pdf
 Language: en/us
 Size: 23045

Or:

+INFO: 0Archived Report (2003)  /03report
gopher.somehost.comic   70      +
+ADMIN: John Jones      jjones@somehost.comic
+DATE-CREATED: 20030907153604
+DATE-MODIFIED: 20030907153604
+DATE-EXPIRES: 20050101000001
+VIEW: text/plain       en/us   10567
+VIEW: text/html        en/us   12043
+VIEW: application/pdf  en/us   23045

...

Yeah, I changed a few other things too, but you get
the general idea.

The first example is more MIME-ish and easier to read,
but harder to parse and less Gopher-like. The second
example is somewhat less human-readable, but
significantly easier to parse and also a lot more in
tune with Gopher. It would be quite easy to parse
either one as a tree or as an event stream.

I really wish they had standardized something like the
above examples instead of the hodgepodge of data
description formats they ended up settling on.

Comments?

__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com