[AG-DEV] [AG-TECH] Continual of AG services

[Philippe d'Anfray]

Bonjour,

> Some of the feedback I think would be useful in knowing, includes: 
> . What groups depends on the use of the Access Grid
> 	o What sort of usage are we talking about?
Here we use AG for technical meeting, seminars and also for performances
in art.
One project in Aristote is to use AG as an infrastructure for "virtual
laboratories".

> . I would like to see an international team (especially those involved in local AG support), that assist with maintaining and operating some of these services in the future.  Does this sound like the best way to operate?

>From the service operating point of wiew AG is  some kind of network of
VenueServers and Bridges. We are maintining a service for local users
but more international coordination would be great.

> . Which services/aspects of the AG are of importance:
> 	o Source code 
> 	o ANL Venue Server 
> 	o ANL Jabber Server
> 	o ANL Bridge Registry
> 	o AG-Dev Certificate Authority
> 	o The accessgrid.org web site (Documentation, Node Listing, QA results, Software downloads) 
> 	o AG-related mailing lists
Also from this point of view, a world-wide "reference"  node like the
ANL Venue-JAbber-Bridge, etc.. is not so important as long as there are
"regional" nodes.  What should really  be centralized is cource code,
mailing lists, documentation may be certificate issuing and a reference
list of bridges..

> For the services listed above, do you have any suggestions or recommendations for these services?  Whist we are talking a good look at these services, is there anything else we should be including? Are there any services we think are no longer required?

There are some things that we really feel are missing in the nowaday AG
    * "asymmetric sessions" where one node can control what the other
participants can look and hear (especially for artistic performances).
    * other clients for sound and video (we tried to interface locally
with "pure data" and it is something we'll probably try to deepen)
    * ipv6 of course (which would solve most  of the multicast issues
(hum ?) ???)
    * a light client somewhat like the PAG portlet (the user do not have
to install anything)
All this kind of developments seems realistic (and feasible) as they
benefit from  the AG infrastructure.

Cordialement

Philippe






-------------- next part --------------
A non-text attachment was scrubbed...
Name: Philippe_d-Anfray.vcf
Type: text/x-vcard
Size: 310 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/ag-dev/attachments/20120312/db5b1617/attachment.vcf>