Greetings John:<br><br>First, thanks for your interest in my questions. Our key point is related to the interaction factor. Our goal is to create an application for managing webinars consisting in a web interface (for planning and schedule them) and a client app. One of our key factors is interaction, as you have to install the complete toolkit even if you are going to use the client in the easiest configuration (personal node). Our idea is to create a lightweight application client that allow people to participate in a venue without installing anything special as we will have only personal nodes (it includes a list of options that will not be used).<br>
<br>Luis,<br><br><div><span class="gmail_quote">2008/2/28, John I. Quebedeaux, Jr <<a href="mailto:johnq@lsu.edu">johnq@lsu.edu</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
You beat me to mentioning that. :-) Essentially what I±m reading here is<br> using a webclient to drive the AG tools... Which is what I recall AG1<br> doing...<br> <br> Luis, I±m some what puzzled about what you see your end result for "video<br>
conferencing" as (i.e. Why are you doing this that different from anything<br> else?) What are your limiting factors here on the client side? What are the<br> client machines like? Networking? Etc. audio, interaction, etc. What's an<br>
example of how you envision using this?<br> <br> Are there particular problems you can point to on the AG 3.x client(s) that<br> make it not really 'usable' as a lightweight client? (I'm not arguing it's<br>
not, just bringing up the question to see what you think!)<br> <br> You say:<br> <br> > ³A web client is one of our possibilities (my favorite one) and looks a hard<br> <br>> matter. One important point for us, is portability of the client, that is why<br>
> we considered the web approach. Other options are a lightweight client<br> > application written in Python, an applet or a Java Web Start application . To<br> > start, we would just implement audio and video transmission, then we could<br>
> extend the application to support all AG functionalities. I would like to know<br> <br>> your opinion about these options.²<br> <br> We used to have this with AG1 as Bob points out. :-) Although, I can see a<br> reason to use a webclient it would bypass (potentially) the need to<br>
install the AGClient with python, etc if you±re enabling all the resources<br> on a single machine (i.e. Non-grid / non-multiple-machine node). Perhaps it<br> could utilize Java instead (Andrew just answered that!)? But then you<br>
mention a lightweight client written in Python which is already where we are<br> at? At least from what I can tell, the AGTk client is very full featured and<br> lightweight at the same time. So, perhaps I should ask what would you remove<br>
to make it lightweight?<br> <br> The reason I'm bringing this up is to explore how you are thinking about it.<br> Obviously the AGTk architecture? Environment? (struggling for the right word<br> there) appeals to you. To me it seems to me we±re already at that point.<br>
I've been able to train, particularly with AG 3.1, users to use the client<br> themselves with little intervention from me (once I get past the networking<br> issues and troubleshooting on that).<br> <br> Wouldn't one would still require VIC & RAT for the audio and video unless<br>
with the newer vics to transmit mpeg4/h264 someone can "connect" in a<br> webclient to view via quicktime or windowsmediaplayer, etc. with some<br> embedded video enabler in the web browser for each video stream? How easy or<br>
cumbersome would it be to view, say, 20 video streams at once? I can see<br> having a web ³client² that enables the tools (is this like VRVS already?)<br> but would still rely on venue servers, bridging servers, etc. chat<br>
capability, etc.? Like we used to have with AG1 and somewhat like we have<br> now.<br> <br> Ok, I wonder what today's roadmap now looks like for AG... Sorry Tom, I<br> brought that up!<br> <br> You also asked:<br> <br>
<br> > And finally, would you recommend us to use AGTk 3.0? How feasible is it<br> <br>> considering the available resources until now??. Thanks again!!!²<br> <br> AG3.1 - it's out, it works. Anyone having significant problems with it? (OS<br>
X users excluded from that question). It±s running very well here in our<br> infrastructure so far on Windows and Linux. We've been upgrading each of our<br> major nodes across the state of Louisiana as we go, and by the time we have<br>
our next big meeting we'll be there (2 weeks). I'm already taking advantage<br> of tools like VPCScreenProducerService, the new VIC capabilities for h261as<br> and jpeg. In the argonne lobby I'm keeping most of the time a 720x480 view<br>
of our LSU Memorial Tower and the I-10 Mississippi river bridge into our<br> city (Baton Rouge) in the back ground from the LSU Campus. It's not bad. Of<br> course the bandwidth is a bit more than the rest...<br> <br>
To me, AG 3.1 (and previous versions) have been ¦lightweight± but of course<br> depend on having the appropriate Python installation to function. Also,<br> perhaps the complexity has to do with the toolkit enabling other<br>
applications from the client and enabling connectivity (or attempting to) in<br> an environment with many video, audio, etc. where there is always a struggle<br> between network security and use.<br> <br> Otherwise, there are so many other ways to communicate particularly if<br>
it±s just a broadcast type of session!<br> <br> -John Q.<br> --<br> John I. Quebedeaux, Jr.; Louisiana State University<br> Computer Manager LBRN; 131 Life Sciences Bldg.<br> e-mail: <a href="mailto:johnq@lsu.edu">johnq@lsu.edu</a>; web: <a href="http://lbrn.lsu.edu">http://lbrn.lsu.edu</a><br>
phone: 225-578-0062 / fax: 225-578-2597<br> <br> <br> <br> From: Robert Olson <<a href="mailto:olson@mcs.anl.gov">olson@mcs.anl.gov</a>><br> Date: Thu, 28 Feb 2008 11:11:32 -0600<br> To: "<a href="mailto:Andrew.Rowley@manchester.ac.uk">Andrew.Rowley@manchester.ac.uk</a>" <<a href="mailto:Andrew.Rowley@manchester.ac.uk">Andrew.Rowley@manchester.ac.uk</a>><br>
Cc: Luis Galárraga <<a href="mailto:lgalarra@fiec.espol.edu.ec">lgalarra@fiec.espol.edu.ec</a>>, "Thomas D. Uram"<br> <<a href="mailto:turam@mcs.anl.gov">turam@mcs.anl.gov</a>>, "<a href="mailto:ag-dev@mcs.anl.gov">ag-dev@mcs.anl.gov</a>" <<a href="mailto:ag-dev@mcs.anl.gov">ag-dev@mcs.anl.gov</a>>, alejandro<br>
<br>moreno <<a href="mailto:ghost482@hotmail.com">ghost482@hotmail.com</a>>, Alejandro Moreno <<a href="mailto:ghost482@yahoo.com">ghost482@yahoo.com</a>>, "Ing.<br> Verónica Macías" <<a href="mailto:mmacias@fiec.espol.edu.ec">mmacias@fiec.espol.edu.ec</a>>, Marisol Villacrés<br>
<<a href="mailto:lvillacr@fiec.espol.edu.ec">lvillacr@fiec.espol.edu.ec</a>><br> <br>Subject: Re: [AG-DEV] Web client for AG<br> <br> <br>Hey, we're back to AG1.<br> <br> On Feb 28, 2008, at 3:17 AM, Andrew Rowley wrote:<br>
<br> > Hi,<br> > <br> > We found that to enable the client to launch external processes, you need<br> > something in addition to the web browser. We decided to use java for this <br> > in both applet and web application forms (an applet is used to talk between<br>
> the web browser and the web start). The web start application does all the<br> > backend work, and the web browser is then used for the gui front end. The<br> > communication to the web application side (which then communicates to the AGTk<br>
> server) is via AJAX we have designed an XMLRPC queuing system for this. <br> > This queue is also used to receive events at the browser gui side (such as a<br> > user joining the session).<br> > <br> > One of the main issues we came across was coping with the user refreshing the<br>
> page. This is an issue for us because we are developing in a portlet<br> > environment. Without this, we could have just said that the page should never<br> > be refreshed I guess.<br> > <br> > Andrew J<br>
> ---------------------------------------------------------<br> ><br> > Andrew G D Rowley<br> > Senior Development Officer<br> ><br> > Research Computing Services<br> > The University of Manchester<br>
> Kilburn Building, Oxford Road<br> > Manchester, M13 9PL<br> ><br> > t : +44 (0) 161 275 0685<br> > e : <a href="mailto:Andrew.Rowley@manchester.ac.uk">Andrew.Rowley@manchester.ac.uk</a><br> > w : <a href="http://www.manchester.ac.uk/researchcomputing">www.manchester.ac.uk/researchcomputing</a><br>
<br>> <<a href="http://www.manchester.ac.uk/researchcomputing">http://www.manchester.ac.uk/researchcomputing</a>><br> <br>><br> > ---------------------------------------------------------<br> ><br> ><br>
> From: <a href="mailto:owner-ag-dev@mcs.anl.gov">owner-ag-dev@mcs.anl.gov</a> [mailto:<a href="mailto:owner-ag-dev@mcs.anl.gov">owner-ag-dev@mcs.anl.gov</a>] On Behalf<br> > Of Luis Galárraga<br> > Sent: 27 February 2008 23:09<br>
> To: Thomas D. Uram<br> > Cc: <a href="mailto:ag-dev@mcs.anl.gov">ag-dev@mcs.anl.gov</a>; alejandro moreno; Alejandro Moreno; Ing. Verónica<br> > Macías; Marisol Villacrés<br> > Subject: Re: [AG-DEV] Web client for AG<br>
> <br> > Thomas,<br> ><br> > Thanks a lot for your help. I feel there is light at the end of the tunnel!!!<br> > However, as you can imagine, we have important time constraints. A web client<br> > is one of our possibilities (my favorite one) and looks a hard matter. One<br>
> important point for us, is portability of the client, that is why we<br> > considered the web approach. Other options are a lightweight client<br> > application written in Python, an applet or a Java Web Start application . To<br>
> start, we would just implement audio and video transmission, then we could<br> > extend the application to support all AG functionalities. I would like to know<br> > your opinion about these options.<br> ><br>
> And finally, would you recommend us to use AGTk 3.0? How feasible is it<br> > considering the available resources until now??. Thanks again!!!<br> ><br> > Regards,<br> > Luis Galárraga<br> > 2008/2/27, Thomas D. Uram <<a href="mailto:turam@mcs.anl.gov">turam@mcs.anl.gov</a>>:<br>
> Hi Luis:<br> ><br> > I'm the tech lead at Argonne for the Access Grid project. I'm very<br> > interested in the work you are proposing, and have some comments:<br> ><br> > - The API documentation has not, as you've noticed, been updated for<br>
> AG3. This needs to be done. I could generate documentation of the web<br> > services interfaces fairly easily, which is necessary since there have<br> > been some changes from AG2.<br> ><br> > - There are a couple ways to approach a web-based client. One is to<br>
> build an "adapter" between the VenueServer and the web browser; this<br> > adapter would accept HTTP from the user, make SOAP calls to the AG<br> > VenueServer, and return HTTP responses to the user. I wrote a basic<br>
> example of this here: <a href="http://www.accessgrid.org/node/971">http://www.accessgrid.org/node/971</a> . Another,<br> > possibly better solution, would be to make the SOAP calls at the client<br> > using a JavaScript SOAP implementation. Both of these leave open the<br>
> question of how to handle the audio and video.<br> ><br> > It's a priority for us to update the documentation, but I can't promise<br> > when that will be done. If we can help answer questions in the<br>
> meantime, please don't hesitate to ask either here on the ag-dev list,<br> > or by emailing me directly.<br> ><br> > Thanks,<br> > Tom Uram<br> ><br> ><br> ><br> > On 2/26/08 3:06 PM, Luis Galárraga wrote:<br>
>> Greetings:<br> >><br> >> I am really interested in Access Grid Development as I take part in a<br> >> small community who is developing a software for videoconferencing<br> >> based on AGTk. At the moment, we are in the design phase and some of<br>
>> us are analyzing the possibility of writing a web client for Venues.<br> >> Of course, there are certain constraints: we only need to use AG in<br> >> the easiest configuration, personal node. We would like to know your<br>
>> opinions about this decision. How difficult and feasible is that?. (We<br> >> have discuss some technical facts and consequences). It is obvious<br> >> that the advantages of doing that are numerous.<br>
>><br> >> Thanks in advance for your contributions to this topic.<br> >><br> >> Regards,<br> >> Luis Galárraga<br> > <br> ><br> ><br> <br> </blockquote></div><br>