> From bert@let.rug.nl Thu Sep 8 06:56:55 1994
> From: Bert Bos <bert@let.rug.nl>
> Subject: DIENST, some comments
> To: davis@DRI.cornell.edu, cjl2@cornell.edu
> Date: Thu, 8 Sep 1994 12:56:34 +0200 (METDST)
> Cc: www-talk@www0.cern.ch (* WWW discussion list )
> An especially nice feature is that it doesn't require any browser
> changes, although a modified browser could offer more functionality.
There are certainly some changes we could wish for. We will mention
some of them at the forthcoming WWW conf in Chicago.
> I think the most important change is in the naming of the data types
> returned by the Dienst server. In nearly all cases the server returns
> data identified as "text/plain" or "text/x-dienst-response", even
> though the data is actually in different formats. This requires the
> client to analyze the request (URL) in order to interpret the
> data. Instead, the server should return distinct types, e.g.:
>
> "application/dienst-services", or
> "application/dienst; type=services", or even
> "dienst/services".
I am not sure I see the value in this. The client knows what request
it has sent, so it should also know the format of the expected response.
So the client would not gain anything by having the format explicitly
typed. A second reason, not as strong, but still valid, is that it's
helpful in debugging to have all responses be in some kind of text.
Since I'm returning text, I might as well label it as text.
The only reason for text/x-dienst-response is that we'd like to be
able to switch to URCs, if that's possible, since they seem to
intended for closely similar purposes.
> I don't see what is "object oriented" about Dienst.
I like to think of Dienst requests as being messages to documents,
e.g. one asks a document what formats it is in, or what pieces it has,
or for it to print itself. I'd also like to leave room for future
expansion, so that different documents could respond to messages
in different ways.
> The prototype implementation seems to use a different URL syntax from
> the one given in the text.
True. The protocol we proposed in the Draft is (we hope) an
improvement over the one we use in the current working version. Several
people have been kind enough to criticise the current version, and
therefore we tried to improve it in the version we propose in the draft.
> One of the "related issues" in section 5 seems to point to distributed
> servers ("Server registration"). Exactly how servers should relay
> queries to each other is unclear to me. This probably needs additional
> mechanisms, not present in the current Dienst protocol.
We have a mechanism in place that is little better than a hack. One
central server keeps a list of all known Dienst servers, and can
return it on request. All other servers poll the central site periodically
to get the new list. To add a new site, someone must edit the central
file. This will certainly not scale, but it should suffice for the nonce.
> PS. "Dienst" appears to stand for "Distributed Interactive Extensible
> Network Server for Techreports", but I wonder if it is a coincidence
> that "dienst" is the Dutch word for "service"?
Ooops. You're right. I made up the acronym after choosing the name.
met vriendelijk groetens,
Jim Davis