[AG-DEV] Web client for AG

Luis Galárraga lgalarra at fiec.espol.edu.ec
Fri Feb 29 14:06:58 CST 2008


Those are very good news, because it makes easier initiatives like ours. Is
it possible that in the future we take advantage of this work? It seems that
the Java client approach is the most popular option in our group until now.

2008/2/29, Andrew Rowley <Andrew.Rowley at manchester.ac.uk>:
>
>  Hi,
>
>
>
> Part of the project is developing a better bridge interfacing
> architecture, so other bridge types (other than QuickBridge) can be used.  I
> have previously developed a StaticBridge, which is one that uses fixed UDP
> port numbers regardless of the venue (e.g. 4 fixed ports for audio and
> video), and have now written a prototype TcpBridge which passes all traffic
> through a single outgoing TCP port.  Interfaces for these bridges will be
> included in the final release, so as long as a TcpBridge is running, clients
> should be able to connect from anywhere.  PAG will also feature network
> configuration detection which will attempt to work out if multicast is
> available and which bridges can be used in the event of a multicast
> failure.  Then, when multicast does not work, it will seamlessly (well,
> maybe with a couple of seconds delay) switch to bridged mode.  PAG also
> features Client-level bridging, which means that all the AG traffic passes
> through a bridge in the client.  This allows the changing of venues,
> encryption and bridges without needing to close the AG service tools (e.g.
> vic and rat), so that you don't have to rearrange your video windows.
>
>
>
> Andrew J
>
> ---------------------------------------------------------
>
>   Andrew G D Rowley
>   Senior Development Officer
>
>   Research Computing Services
>   The University of Manchester
>   Kilburn Building, Oxford Road
>   Manchester, M13 9PL
>
>   t :  +44 (0) 161 275 0685
>   e :  Andrew.Rowley at manchester.ac.uk
>   w :  www.manchester.ac.uk/researchcomputing
>
> ---------------------------------------------------------
>   ------------------------------
>
> *From:* shamantobi at gmail.com [mailto:shamantobi at gmail.com] *On Behalf Of *Luis
> Galárraga
> *Sent:* 28 February 2008 18:26
> *To:* Andrew.Rowley at manchester.ac.uk
> *Cc:* Thomas D. Uram; ag-dev at mcs.anl.gov; alejandro moreno; Alejandro
> Moreno; Ing. Verónica Macías; Marisol Villacrés
> *Subject:* Re: [AG-DEV] Web client for AG
>
>
>
> Hi,
>
> That solution is really interesting as I can see, however according to the
> exposed ideas, our time and resources constraints make it a risky option. I
> have another question. The idea of developing a web client is to make AG
> client more ubiquitous and accessible to everyone. Do you use any kind of
> bridging for cases in which the client does not have access to a multicast
> network??.
>
> 2008/2/28, Andrew Rowley <Andrew.Rowley at manchester.ac.uk>:
>
> Hi,
>
>
>
> We found that to enable the client to launch external processes, you need
> something in addition to the web browser.  We decided to use java for this –
> in both applet and web application forms (an applet is used to talk between
> the web browser and the web start).  The web start application does all the
> backend work, and the web browser is then used for the gui front end.  The
> communication to the web application side (which then communicates to the
> AGTk server) is via AJAX – we have designed an XMLRPC queuing system for
> this.  This queue is also used to receive events at the browser gui side
> (such as a user joining the session).
>
>
>
> One of the main issues we came across was coping with the user refreshing
> the page.  This is an issue for us because we are developing in a portlet
> environment.  Without this, we could have just said that the page should
> never be refreshed I guess.
>
>
>
> Andrew J
>
> ---------------------------------------------------------
>
>   Andrew G D Rowley
>   Senior Development Officer
>
>   Research Computing Services
>   The University of Manchester
>   Kilburn Building, Oxford Road
>   Manchester, M13 9PL
>
>   t :  +44 (0) 161 275 0685
>   e :  Andrew.Rowley at manchester.ac.uk
>   w :  www.manchester.ac.uk/researchcomputing
>
> ---------------------------------------------------------
>   ------------------------------
>
> *From:* owner-ag-dev at mcs.anl.gov [mailto:owner-ag-dev at mcs.anl.gov] *On
> Behalf Of *Luis Galárraga
> *Sent:* 27 February 2008 23:09
> *To:* Thomas D. Uram
> *Cc:* ag-dev at mcs.anl.gov; alejandro moreno; Alejandro Moreno; Ing.
> Verónica Macías; Marisol Villacrés
> *Subject:* Re: [AG-DEV] Web client for AG
>
>
>
> Thomas,
>
> Thanks a lot for your help. I feel there is light at the end of the
> tunnel!!! However, as you can imagine, we have important time constraints. A
> web client is one of our possibilities (my favorite one) and looks a hard
> matter. One important point for us, is portability of the client, that is
> why we considered the web approach. Other options are a lightweight client
> application written in Python, an applet or a Java Web Start application .
> To start, we would just implement audio and video transmission, then we
> could extend the application to support all AG functionalities. I would like
> to know your opinion about these options.
>
> And finally, would you recommend us to use AGTk 3.0? How feasible is it
> considering the available resources until now??. Thanks again!!!
>
> Regards,
> Luis Galárraga
>
> 2008/2/27, Thomas D. Uram <turam at mcs.anl.gov>:
>
> Hi Luis:
>
> I'm the tech lead at Argonne for the Access Grid project.  I'm very
> interested in the work you are proposing, and have some comments:
>
> - The API documentation has not, as you've noticed, been updated for
> AG3.  This needs to be done.  I could generate documentation of the web
> services interfaces fairly easily, which is necessary since there have
> been some changes from AG2.
>
> - There are a couple ways to approach a web-based client.  One is to
> build an "adapter" between the VenueServer and the web browser; this
> adapter would accept HTTP from the user, make SOAP calls to the AG
> VenueServer, and return HTTP responses to the user.  I wrote a basic
> example of this here:  http://www.accessgrid.org/node/971 .  Another,
> possibly better solution, would be to make the SOAP calls at the client
> using a JavaScript SOAP implementation.  Both of these leave open the
> question of how to handle the audio and video.
>
> It's a priority for us to update the documentation, but I can't promise
> when that will be done.  If we can help answer questions in the
> meantime, please don't hesitate to ask either here on the ag-dev list,
> or by emailing me directly.
>
> Thanks,
> Tom Uram
>
>
>
> On 2/26/08 3:06 PM, Luis Galárraga wrote:
> > Greetings:
> >
> > I am really interested in Access Grid Development as I take part in a
> > small community who is developing a software for videoconferencing
> > based on AGTk. At the moment, we are in the design phase and some of
> > us are analyzing the possibility of writing a web client for Venues.
> > Of course, there are certain constraints: we only need to use AG in
> > the easiest configuration, personal node. We would like to know your
> > opinions about this decision. How difficult and feasible is that?. (We
> > have discuss some technical facts and consequences). It is obvious
> > that the advantages of doing that are numerous.
> >
> > Thanks in advance for your contributions to this topic.
> >
> > Regards,
> > Luis Galárraga
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/ag-dev/attachments/20080229/08931c2e/attachment.htm>


More information about the ag-dev mailing list