Venues 2.0 Client

[Ivan R. Judson]

Cool; I think we're on the same page then.  The next time we're both at 
ANL I'll describe the stuff we've got as a basis for 2.0 and how it 
provides (I believe) exactly this kind of infrastructure.

--Ivan

On Thu, 24 Oct 2002, Rick Stevens wrote:

> Some thoughts on Node management.
> 
> We've been thinking for some time that we want to broaden the definition of 
> a node for the AG to include a variety
> of display and interaction devices associated with the core AG 
> resources.  An example of this would be a micromural
> that is associated with a node.  When the micromural is to be used with the 
> AG node it would need to be registered
> somehow with the node as an available capability and we would want to be 
> able to discover its presence etc.   Seems
> that the AG node resource collection would need to be managed as a 
> collection of resources (have some description
> of the associated devices etc.), have some ability to manage those resource 
> (reserve, allocate, digitally control,
> install and launch programs,  check status etc.) and to 
> monitor.   Informally I've been thinking about nodes
> at two levels.  Those that are part of the installed infrastructure (likely 
> to be part of the dedicated systems
> in the room, etc.) and those that are temporarily associated with the node 
> (laptops, pdas etc.).  Those in the second
> category might want the ability to associate themselves with the main AG 
> node such that venue transitions are
> automatically propagated etc.   Its not clear to me currently how to think 
> about security for the node as a whole.
> Security models for the Grid seem to be based on the concept of a user, but 
> the AG node is more likely to be associated
> with a space or group, even though their might be an operator as well.  I 
> dont know if we have talked to the Globus
> folks about Group certificates.  But that might something for us to do.
> 
> In the back of my mind I'm thinking that we need some kind of active space 
> services that tie things together in a way
> that would enable one to write (desgin?) applications for entire rooms.
> 
> At 12:26 PM 10/18/2002 -0500, Thomas Uram wrote:
> 
> >I've been working on implementation of the Node Management infrastructure, 
> >and have been developing a client to exercise the infrastructure.  This 
> >has given me a good sense of what the Node Management client needs to do.
> >
> >We should be able to have a productive discussion, with the different 
> >ideas and prototypes we have.  We should meet one day next week when Ivan 
> >and Bob are back.
> >
> >
> >Tom
> >
> >
> >Rick Stevens wrote:
> >
> >>Good idea to collect these requirements.. so at some point we can make the
> >>decision if we re implement from scratch or if we can reuse any of the 
> >>pre-prototype.
> >>
> >>At 11:24 AM 10/18/2002 -0500, Terry Disz wrote:
> >>
> >>>Ivan,
> >>>
> >>>The venue client we are now using is what I call a pre-prototype. I am sure
> >>>Bob can elaborate when he gets back, but from my point of view, it serves
> >>>two purposes: To exercise the VV functionality and to provide a testbed for
> >>>the docking client. Towards that end, it is more or less hard coded to a
> >>>venue but does exercise the venue interface for enter, (but no navigation),
> >>>it implements all security Bob has been working on, it exercises the venue
> >>>interface for user objects, it has no node management functions, it provides
> >>>a client venue interface so the docking tools can gain access to user and
> >>>venue information. These latter functions were all in the original WS
> >>>docking architecture. I continue to expand it as needed for technical
> >>>research issues or other experiments. You can find it and the entire code
> >>>base in the fl cvs tree under VV2. I am running an experimental version now
> >>>that I have not checked in, which has added functionality.
> >>>
> >>>All that being said, it certainly is high time we started to figure out what
> >>>the entire suite of requirements are, including UI, for a venues client we
> >>>want to deliver. I can start by extracting requirements of the Venues Client
> >>>from the docking documents and maybe Tom or you can contribute some node
> >>>management requirements.
> >>>
> >>>Terry
> >>>
> >>>
> >>>
> >>> > -----Original Message-----
> >>> > From: owner-ag-dev at mcs.anl.gov [mailto:owner-ag-dev at mcs.anl.gov]On
> >>> > Behalf Of Ivan R. Judson
> >>> > Sent: Thursday, October 17, 2002 2:16 PM
> >>> > To: 'Ag-Dev at Mcs. Anl. Gov'
> >>> > Subject: Venues 2.0 Client
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > Howdy,
> >>> >
> >>> > I'd like to start a discussion about a key part of AG 2.0 that isn't
> >>> > represented yet by any of our arch or design documents. The Venues
> >>> > Client.
> >>> >
> >>> > I know Chris has been working on some form of a client, but I'm
> >>> > wondering what discussion has taken place that's driving that client
> >>> > development. Can someone summarize the current client development, the
> >>> > intent of the client, and point me at any design documents that might
> >>> > exist for the client? That'd be a great place to start this discussion.
> >>> >
> >>> > Thanks,
> >>> >
> >>> > --Ivan
> >>> >
> >>> > ..........
> >>> > Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
> >>> > Futures Laboratory .~.  630 252 0920
> >>> > Argonne National Laboratory .~. 630 252 6424 Fax
> >>> >
> >>> >
> >>
> >>
> >
> >
> 
>