users@grizzly.java.net

Re: [Q] Grizzlets update clients connected to different servers

From: ALT Mobile DEV <dev_at_altmobile.com>
Date: Wed, 16 Jan 2008 14:58:20 -0500

Hi,

my response is embedded... thanks again


--Zaid

altmobile.com

On Jan 16, 2008, at 11:38 AM, Jeanfrancois Arcand wrote:

> Salut,
>
> ALT Mobile DEV wrote:
>> thanks for the quick responses.
>> Will this also support non-cometd Grizzlets where the client does
>> _not_ specify a comet path.
>
> Yes it will.
>
>> In our Dynamic Mashup Server, we want to allow the client to
>> specify the behavior of the server through URL parameters.
>> So an AJAX client will use a URL such as http://altmobile.com:xxx
>> and a long-polling Comet client will use a URL such as http://altmobile.com
>> :xxx?use-comet&refresh-increment=5
>> and a Bayeux Comet client will use a predefined Comet context path
>> such as the URL http://altmobile.com:xxx/comet?use-comet&refresh-
>> increment=5
>
> OK let me ask a couple of questions. Here you seems to use two
> concepts:
>
> (1) Comet: Some Ajax clients send http request and the body (the
> message) is based on some custom protocol/messages.
>
> (2) Cometd/Bayeux: Some Ajax clients send http message and the body
> (the message) is written using Bayeux (JSON).
>
> This is quite interesting If I understand properly :-)

[ZAID] yes, that is correct. Much like you created Grizzlets to
simplify Comet and Servlet programming and deployment and etc. we have
also simplified mash-up programming, testing, and deployment.
Conceptually, a mash-up aggregates parts of 1 or more remote web sites
with some local content. Perhaps a mash-up would be a few paragraphs
from Wikipedia on Comet, the titles of your blogs on Comet excluding
JRuby and GlassFish, a few pictures and bios of the Grizzy team, and a
table of the JAR files for the various Grizzly bundles. That's about
10 http requests to create this virtual tutorial web site on Grizzly.

Our Dynamic Mashup Server provides virtualized Web 2.0 containers
which isolate each mash-up. The user can consume the mash-up as a
JavaFX client, iPhone client, Apple Dashboard widget, MS Vista Gadget,
RSS feed, text-to-speech audio, etc, etc. The Dynamic Mashup Server
uses code generation to output the appropriate type based on the
client request and client capabilities.

The glue between our Web 2.0 containers and the clients is of course
Grizzly but the end user's mental model is about the XSL that creates
their mash-up page and the URL parameters which control the Dynamic
Mashup Server's output.

So we want the end user to be able to consume their mash-up with a
long-polling Comet client by using the URL parameter "use-comet" just
like if the user was visually impaired she could use the parameter
"use-TTS" to get a text-to-speech audio of the mash-up results. It's
not very RESTful, but it's the best approach for mash-up programming
or else you would have 15+ unique URLs from each mash-up which is not
a manageable solution for the end user.

So, yes we hope to run both Comet and Cometd on the same port
hopefully using the nice Web 2.0 container friendly POJO model that
Grizzlets provide.



>
>
>> That's our plan for Grizzly. Do you think that this is doable with
>> the Grizzlet architecture?
>
> Yes it will, but you gonna need to bootstrap/embed the grizzly-
> cometd module AND the Grizzlet (like you already did). Now when you
> listen to a port (let say 3434), can that port receive both comet
> and cometd requests? Currently a port support comet *or* cometd, but
> not both (this is quite simple to implement btw).
>
> Thanks
>
> -- Jeanfrancois
>
>
>> thanks.
>> --Zaid
>> http://altmobile.com
>> On Jan 15, 2008, at 10:11 PM, Jeanfrancois Arcand wrote:
>>> Hi,
>>>
>>> ALT Mobile DEV wrote:
>>>> Hi,
>>>> I'm running multiple servers in the same JVM where each server is
>>>> associated with a different instance of the same Grizllet class.
>>>> Each server of course is bound to a different port.
>>>> Confusingly, the unique content from each Grizzlet is pushed to
>>>> all clients irrespective of the server:port they are connected.
>>>
>>> Yes :-( I didn't expected that Grizzly will be used like you just
>>> explained. Mainly, since Grizzly build on top of Grizzly Comet,
>>> the CometHandler I did for Grizzly is registered as '/comet'.
>>> Since there is only one CometEngine (this is a singleton), all
>>> Grizzlet will be invoked when the Grizzly Comet do a push, as
>>> internally it will do:
>>>
>>> cometContext.notify(...);
>>>
>>> and the cometContext is bind to 'comet'.
>>>
>>>> It seems that the AsyncConnection is shared across all Grizzlets
>>>> and servers.
>>>> I was expecting that:
>>>> Grizzly server = unique port + unique Grizzlet instance + unique
>>>> comet context.
>>>
>>> OK I've just added a new API to let you customize the
>>> cometContextName. When you initialize the GrizzlyAdapter, just
>>> pass the name of the cometContext you want to use. In your case,
>>> it can be the just the port like the following:
>>>
>>>> 113 AsyncHandler asyncHandler = new
>>>> DefaultAsyncHandler();
>>>> 114 asyncHandler.addAsyncFilter(new CometAsyncFilter());
>>>> 115 selectorThread.setAsyncHandler(asyncHandler);
>>>> 116 117 118 GrizzletAdapter adapter = new
>>>> GrizzletAdapter(String.valueOf(port));
>>>> 119 selectorThread.setAdapter(adapter);
>>>> 120 Grizzlet grizzlet =
>>>> (Grizzlet)loadInstance(grizzletClassName);
>>>> 121
>>>
>>> Try it and let me know if that works :-) I've uploaded the new
>>> artifacts to the m2 repository, or you can rebuild the comet
>>> module to get the changes.
>>>
>>> Thanks
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>
>>>> thanks for any help.
>>>> --Zaid
>>>> http://altmobile.com
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>