From: Peter J. Nuernberg (pnuern)
Date: Mon 09 Jun 1997 - 18:18:04 CDT
> ...I'll send a .gif picture to you in a separate mail; Note, we do
> not claim that this is a reference architecture. It simply helped us during
> our discussion on OHP). In order to have these basic components talking to
> each other there should rather be a series of OHPs than one single
> protocol: especially a DMP (Document Management Protocol) would often be
This picture is not posted in the protocol area of the ohs www site, just for reference to those following this discussion thread.
> (I think I do not really understand your point of 'ignoring' the SM
> on 'a logical addressing level').
> >In any event, suppose you had the following scenario. An app
> >communicates to a link service through a session manager. Ignoring
> >for a moment the collaboration problems with this (don't hit me,
> >J=F6rg!), can the session manager be abstracted out of this discussion?
> >It seems to me that the link service can logically address (in the
> >header) it's messages to the app but physically route them to the
> >session manager.
Well, I think that Jim touched on this with the diagram of the protocol stack. The session manager can be (I still think) removed from the OHP discussion, unless we want to do something with this version other than basic link functionality.
>From the view of the app, does it need to know that a session manager
exists? Does the link server? (I understand that if there is a session manager, you may pass messages to/from it, so at _that_ level, you do need to know, but I'm speaking from the point of view of the logical semantics of the operations.)
As far as I can tell, Sigi and Hugh have said that this information _is_ occasionally needed, while Jim contends it doesn't. Perhaps we could solve this with a scenario! Sigi, Hugh, could you outline a scenario (not necessarily the full thing, although that would be great, just the basics) in which either the app or link server needs to know this information?
This archive was generated by hypermail 2.1.5 : Tue 13 Aug 2002 - 07:20:44 CDT