From: Sigi Reich (sr_at_ecs.soton.ac.uk)
Date: Wed 28 Apr 1999 - 04:34:21 CDT
thanks for making some very good points! As mentioned earlier, we had a different notion of contexts when designing the DTD. Our feeling was that everything should happen WITHIN a context(Set) so this is why contexts are part of the message header.
But as you point out, ideally the message header should only be concerned with information that is specific to the sending/receiving of the actual messages (this actually raises an interesting point as to where one would put information such as certificates for encryption/security, etc.)
What concerns the idea of adding contexts as additional parameters to (some) messages I would think that clearly not only the CREATE* functions should take a context parameter but also the MODIFY* functions (and what about others such as FollowLink?).
Some other ideas:
- what would you think about making the current context(s) explicit by having setContexts(IDSet) and getContexts() functions? This would avoid having to change some functions so that they incorporate contexts (whereas others would not have contexts) and it would also be a cleaner way than setting an environment variable.
At 08:10 16/04/99 -0500, you wrote:
>Our problem with the current dtd is that the ContextIdSet is part of the
>messageheader rather than a parameter in the message.
>As you may remember the Århus implementation is made as a set of interfaces
>where we have operations such as LINKCREATE, ENDPOINTCREATE taking relevant
>parameters. When we communicate over the wire these operations are
>translated into message according to the DTD. The convention here is:
>- the messageheader information is added by the infrastructure without
>intervention by the programmer using the interface.
>- the messagebody contains the paramters that the programmer supplied to
>If we take the above scenario, it is inconvenient for the programmer to
>have to modify some "environment" variable to hold the id of the context in
>question before s/he issues the LINKCREATE operation targeted at one
>context and then modifiy that variable again before issuing the NODECREATE
>operation targeted at a another context.
>We could of course modify the LINKCREATE operation such that it takes a
>contextIDSet as a parameter and then use that to explicitly modify the
>messageheader. But we see this as a not very clean solution since we then
>have some operation parameters that go into the messageheader and some that
>go into the messagebody.
>Moreover, not all messages need to take place within one or more Contexts.
>We beleive that at least the following messages should have a ContextIDSet
>parameter: LINKCREATE, ENDPOINTCREATE, ANCHORCREATE, NODECREATE,
>The corresponding delete operations may not need the contextIDset since we
>could implement the structure server such that it guarantees that if a
>Link, Endpoint, Anchor, Node, PSpec or Computation is deleted then it
>automatically removes the objectID from all the Contexts in which it is a
>member. This would emancipate the user from remembering all the relevant
>contexts to enumrate for a delete operation.
>We can of course make either the environment variable workaround or the
>splitting of parameters into header and body parameters, but we would
>prefer the more clean solution with the ContextIDset as part of the
>messagebody in a revision of the darmstad.dtd.
>/Kaj & Lennert
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:21:16 CDT