[AG-DEV] Web client for AG

Thu Feb 28 11:56:45 CST 2008

You beat me to mentioning that. :-) Essentially what I¹m reading here is
using a webclient to drive the AG tools... Which is what I recall AG1
doing...

Luis, I¹m some what puzzled about what you see your end result for "video
conferencing" as (i.e. Why are you doing this that different from anything
else?) What are your limiting factors here on the client side? What are the
client machines like? Networking? Etc. audio, interaction, etc. What's an
example of how you envision using this?

Are there particular problems you can point to on the AG 3.x client(s) that
make it not really 'usable' as a lightweight client? (I'm not arguing it's
not, just bringing up the question to see what you think!)

You say: 

> ³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.²

We used to have this with AG1 as Bob points out. :-) Although, I can see a
reason to use a webclient  it would bypass (potentially) the need to
install the AGClient with python, etc if you¹re enabling all the resources
on a single machine (i.e. Non-grid / non-multiple-machine node). Perhaps it
could utilize Java instead (Andrew just answered that!)? But then you
mention a lightweight client written in Python which is already where we are
at? At least from what I can tell, the AGTk client is very full featured and
lightweight at the same time. So, perhaps I should ask what would you remove
to make it lightweight?

The reason I'm bringing this up is to explore how you are thinking about it.
Obviously the AGTk architecture? Environment? (struggling for the right word
there) appeals to you. To me it seems to me we¹re already at that point.
I've been able to train, particularly with AG 3.1, users to use the client
themselves with little intervention from me (once I get past the networking
issues and troubleshooting on that).

Wouldn't one would still require VIC & RAT for the audio and video unless
with the newer vics to transmit mpeg4/h264 someone can "connect" in a
webclient to view via quicktime or windowsmediaplayer, etc. with some
embedded video enabler in the web browser for each video stream? How easy or
cumbersome would it be to view, say, 20 video streams at once? I can see
having a web ³client² that enables the tools (is this like VRVS already?)
but would still rely on venue servers, bridging servers, etc. chat
capability, etc.? Like we used to have with AG1 and somewhat like we have
now.

Ok, I wonder what today's roadmap now looks like for AG... Sorry Tom, I
brought that up!

You also asked: 

> And finally, would you recommend us to use AGTk 3.0? How feasible is it
> considering the available resources until now??. Thanks again!!!²

AG3.1 - it's out, it works. Anyone having significant problems with it? (OS
X users excluded from that question). It¹s running very well here in our
infrastructure so far on Windows and Linux. We've been upgrading each of our
major nodes across the state of Louisiana as we go, and by the time we have
our next big meeting we'll be there (2 weeks). I'm already taking advantage
of tools like VPCScreenProducerService, the new VIC capabilities for h261as
and jpeg. In the argonne lobby I'm keeping most of the time a 720x480 view
of our LSU Memorial Tower and the I-10 Mississippi river bridge into our
city (Baton Rouge) in the back ground from the LSU Campus. It's not bad. Of
course the bandwidth is a bit more than the rest...

To me, AG 3.1 (and previous versions) have been Œlightweight¹ but of course
depend on having the appropriate Python installation to function. Also,
perhaps the complexity has to do with the toolkit enabling other
applications from the client and enabling connectivity (or attempting to) in
an environment with many video, audio, etc. where there is always a struggle
between network security and use.

Otherwise, there are so many other ways to communicate  particularly if
it¹s just a broadcast type of session!

-John Q.
-- 
John I. Quebedeaux, Jr.; Louisiana State University
Computer Manager LBRN; 131 Life Sciences Bldg.
e-mail: johnq at lsu.edu; web: http://lbrn.lsu.edu
phone: 225-578-0062 / fax: 225-578-2597

From: Robert Olson <olson at mcs.anl.gov>
Date: Thu, 28 Feb 2008 11:11:32 -0600
To: "Andrew.Rowley at manchester.ac.uk" <Andrew.Rowley at manchester.ac.uk>
Cc: Luis Galárraga <lgalarra at fiec.espol.edu.ec>, "Thomas D. Uram"
<turam at mcs.anl.gov>, "ag-dev at mcs.anl.gov" <ag-dev at mcs.anl.gov>, alejandro
moreno <ghost482 at hotmail.com>, Alejandro Moreno <ghost482 at yahoo.com>, "Ing.
Verónica Macías" <mmacias at fiec.espol.edu.ec>, Marisol Villacrés
<lvillacr at fiec.espol.edu.ec>
Subject: Re: [AG-DEV] Web client for AG

Hey, we're back to AG1.

On Feb 28, 2008, at 3:17 AM, Andrew Rowley wrote:

> 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
> <http://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
>  
> 
> 