On Fri, 9 Feb 2007, Mark Taylor wrote:
> On Fri, 9 Feb 2007, Doug Tody wrote:
>
> > Hi Mark -
> >
> > I think we are actually saying the same thing. If we define a
> > standard inter-tool messaging protocol and implement it on top of,
> > e.g., D-Bus, you client does not talk directly to D-Bus, it talks to
> > an implmentation of the defined messaging standard which just happens
> > to use D-Bus, MPI, Ice, or whatever internally. It is not a compliant
> > implementation unless a standard interface is presented which isolates
> > the client from the underlying messaging infrastructure used.
>
> good, I'm quite happy with that. In that case I don't think there's
> much call for discussion here about what underlying messaging
> infrastructure is used, since as you say that's a matter for the
> implementations. What we need to get straight is what the
> client-facing interface should look like.
[A few comments and questions. I plan to update the Twiki later today with a list of what appear to be agreed points and those still under debate so they can be distilled more easily from a very lively exchange and other comments appearing on the Twiki questions page.]
I would remind you of an earlier comment that we agree on at least one transport protocol that all compliant implementations support, so I think there is still some room for discussion on this point. BTW, I checked the RFC for HTTP and is only says that TCP sockets will 'usually' be used, the protocol itself doesn't preclude any other form of transport and so your example is very relevant.
I haven't yet heard a call for the definition of a standard API but I think we need at least a straw description of one to talk about the behavior of the interface, e.g. does a sendMessage require an ACK, is there some standard "header" to a message, is there negotiation between apps when connecting to determine compatability, is a message immutable between transport methods or is a PLATSIC 'loadImage' message as good as a D-Bus one, etc.
Lastly, people are still talking about the/a 'hub': My understanding is that this is an artifact of the RMI used in PLASTIC, but some apps have embedded hubs and in other cases it's a standalone process. PLASTIC apps all connect to the hub in a point-to-point manner (please correct me if I'm wrong so far). So, is the 'hub' in question a simple registry of apps and mini-router or does it, or the idea of it, serve some other purpose we need to preserve? Can a "$HOME/.ivoamsgrc" directory containing user preferences, a local app capability registry, caches, etc serve the same purpose (it's a well-known location to all apps so provides separation between users on the same machine, apps can update their capabilities db w/ each new version, scribble a file saying who's "connected", no real Registry lookups so it'll continue to work while you're on the plane, etc)
-Mike Received on 2007-02-09Z18:14:36