Derek: I've generated documentation from the toolkit code, and posted it in the developer documentation pages:
http://www.mcs.anl.gov/fl/research/accessgrid/documentation/developer.html Any of the AG components that are exposed via SOAP are represented by an interface wrapper ('IW') class; for example, the venue server's SOAP interface is accessible via AccessGrid.VenueServer.VenueServerIW . If you find that documentation for an IW class is somewhat lacking, you can look at the IW's symmetric counterpart, the interface or 'I' class (e.g. AccessGrid.VenueServer.VenueServerI); the 'I' classes are in some cases better documented. I'd encourage people to take a look and, by all means, "write tools/add-ons and be happy". We'll be adding to the developer documentation pages soon, to facilitate external development. Tom On 04/13/05 09:48, Derek Piper wrote: > > Hi, > > Since the 'brainstorming' appears to have died down a lot.. What > about a published API for interacting with the venue server? Then we can > all go write our tools/add-ons and be happy. Good ones can be > incorporated into the main AG software, i.e. pass codes etc. > > Derek > > Ivan R. Judson wrote: > >> The beauty of Adam's suggestion is that it's exactly what the AG team has >> been trying to get enough time to build. This is the kind of work we'd >> like >> to see -- but I don't believe the NCSA scheduler has been released yet >> for >> others to hack on it. The work I believe is a small amount using the >> existing interfaces that are available. >> >> If this can't be done in short order, I support Brian's point that for >> most >> users a passcode/password -- similar to what is used by conference >> calls or >> web meeting software, should be sufficient _to gain access_ to the >> venue (to >> get past the bouncer), but it's really of *no* use if the communication >> within the venue isn't secure -- then as Jennifer points out, you're only >> relying on obscurity. >> >> Who wants to hack on the scheduling software (either NCSA's or a new >> one)? >> That's where the interesting "automation" is. It won't solve all the >> ad-hoc >> stuff, but it'd go a long way towards solving a lot of the mundane >> problems... >> >> --Ivan >> >> >>> -----Original Message----- >>> From: owner-ag-t...@mcs.anl.gov [mailto:owner-ag-t...@mcs.anl.gov] On >>> Behalf Of Adam Taylor >>> Sent: Monday, April 11, 2005 11:01 AM >>> To: ag-t...@mcs.anl.gov >>> Subject: RE: [AG-TECH] AG security and multicast ? >>> >>> My two cents... >>> >>> To bad there wasn't a way that when you go to confirm you reservation >>> in the AG Scheduler you must enter the DN of the site you will be at >>> to confirm your reservation. Then, 5 min or so before the meeting >>> starts, a background process (something that can talk to the venue >>> server and scheduler) reads in the DNs from the scheduler for that >>> room and time and sets the ACL for that room for that given scheduled >>> time block. When that meeting is over, the background process >>> removes that ACL for that room and creates another one for the next >>> meeting in that room. If there is more then 30 min or so between >>> meetings then the background process just removes the ACL for that >>> period of time. Just make sure all rooms are encrypted (different >>> key per meeting or something like that) and that should make it >>> pretty secure. >>> >>> At least in my head it does :-) >>> >>> Adam Taylor >>> Computing Center >>> University of Louisiana at Monroe >>> >