Access Grid Meeting 10/01/02 Attendees: NCSA CLRC NewMIC Manchester - Mike Daw Sydney BU - Jennifer EVL - FZJ LANL UMontana Chris Osland - Rutherford Chris - Sydney CHPC Utah Boeing Vrije University Pervasive Technologies SDSC - mgates University of Buffalo Voyager Mike Daw: So users may need to authorize for the venue and for Services separately? Ivan: Yes, the current thought is that separate authorization will be required. This makes sense because the authorization policies will likely differ between services and other objects. Mike Daw: Is there any thought on inheriting authorization? Ivan: ... Alan/EVL: Will Voyager be able to record and playback any stream? Ivan: Yes, Voyager will be extended to handle the different stream types. Workspace Docking Terry: Re: storage for docking: UCL has talked about developing peer-to-peer sharing (using multicast?) Jennifer: I'm unclear about the user interface for workspace docking. Will things like DPPT and VNC be obsoleted by docking? Ivan: The first emphasis is on sharing of data. Docking will allow users interfaces to launch applications outside of the system. Providing docking enables users to get at venue data, users, and interfaces to develop their own collaborative applications. So, existing applications will not be obsoleted. So, collaborative applications is not something we're specifically targeting for 2.0. We will be targeting collaboration and the sharing of data. Other applications may be developed to treat the data differently, so a power point document in a venue might be handled differently for users with different applications. We're going as far out to collaborative applications as we can, without specifically developing them. In later releases, we will develop more collaborative applications. Jennifer: Users are very interested in collaborative applications. Should we, in the short term, point them at existing collaborative applications outside of the AG? For example, collaborative document editing. Ivan: In the very short term, yes. AG2 will provide interfaces for developing collaborative applications. There will be nothing that prevents users from writing a collaborative document editing program, or using an existing one, and making it work within the AG. Terry: Docking provides a framework for developing applications which may be launched and controlled remotely, if the remote user allows it. We have a prototype which shows this now. EVL: I think a device should have services... Ivan: We don't have a mechanism for exposing devices in 2.0. Devices are exposed through a service. EVL: What will identify a user on the AG? Ivan: Almost certainly a Globus certificate. And a distinguish name. Within the AG, users will have a profile, which identifies other properties of the user in addition to that required for identification. mgates@sdsc:Is the client application to be run only on the node, or is it something that the meeting users will be able to run off of their laptops to access the venue services? Ivan: The client application is in fact to be run only on the node, but nodes will be something that is available to all users, whether it be a laptop or a full-blown four machine node, or a cave, or however people implement nodes. Terry: So, it can be run on a laptop, as long as you call the laptop a node. agtech_EVL: Human factors folks should get involved early on to create a positive user environment. Ivan: We need input from many different sources on user interface. If people have suggestions for user interface, they should be sketching what they think would be usable user interfaces and sending them via email. The more people we have involved in that type of activity, the better chance we have to avoid developing a system for engineers. Node Management agtech_EVL: Will AG API be language specific or language agnostic? Ivan: Interfaces will be SOAP/WSDL, to permit applications written in any language to interface with the AG. We are being careful during architecture and design to keep interface separate from implementation to permit refactoring the interface only if the next new technology is not SOAP/WSDL. Mike Daw: Where do vic and rat fit into this, if at all? Will they be part of the AG2 release? Ivan: Vic and rat do fit in AG2, and would likely be wrapped in a service. Whether vic and rat source is included in the open source development of AG2 is a hard question. Mike Daw: So, will these tools be supported by you? Ivan: This week there has been indication out of Berkeley that their funding will run out at the end of this year. There is a lot of pressure from vendors to look at solutions for doing media capture and distribution. We'll have to go through a community discussion to determine the best tools. We will be flexible in what we want to support. As for media tools that ensure the success of the AG, we may have to adopt support for OpenMash, if that benefits the community. We are targeting Linux and Windows, so we must select solutions that support both platforms. We would probably try to incorporate as much functionality from the UCL vic in to the OpenMash vic as possible. OpenMash does not have ny security infrastructure, and that is clearly a critical shortcoming. agtech_EVL: How would private resources be made to become shared resources? Ivan: When you enter a venue, your user profile is sent to the venue. The user profile describes which resources you have available. agtech_EVL: Will there be a scripting language for node management just to automate things for example? Ivan: AG2 will be written in Python, which may be considered a scripting language. We will not provide some new built-in scripting language like JavaScript.