wicketstuff-push: centralizing requests

[Xavier Hanin <xa...@gmail.com>]

Hi,

I'm currently using wicketstuff-push to push events to a page and it works
pretty well, but not well enough. Before trying to move to a comet based
implementation, I would like to improve the timer based implementation. In
the current implementation you got as many AjaxTimer as you install the push
on components on the same page. So if you have three components requiring
push, you will have three requests each x seconds, to poll for push events
from the three components. This would be much more efficient if I had only
one request polling for all push events sent by all components on the
page...

Hence my first thought was to add the timer behavior to the page instead of
the component, and verify that the same kind of behavior is not already
installed before installing a new one. The problem is that when I install
the behavior the component doesn't know its page. So I have to do something
at this time, and then later when I know the page make sure that only one
behavior is actually rendered.

I see two solutions to this problem:
- Add one timer behavior to each component (as today), and then when
rendering the component use the wasRendered/markRendered methods of
IHeaderResponse to render only one of them (using the isEnabled method to
disable it if another similar one has already been rendered). But then I
will have to update all the non rendered behaviors so that push events sent
to them are actually sent to the only behavior which is rendered.
- Modify the API of the push service and ask to enable push on a page before
actually using push on components on the page. This would actually install a
unique timer behavior on the page. Then when installing push on a component
I could simply add something which could be located by the unique timer on
the page to collect all push events (maybe a disabled behavior)

Now that I expose the two options I think I prefer the first one. But I
would like to gather feedback from experienced wicket developers to see if
I'm not missing something or if you have better ideas about how to implement
what I want.

Thanks,

Xavier
-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/

Re: wicketstuff-push: centralizing requests

[Xavier Hanin <xa...@gmail.com>]

On 7/11/07, Vincent Demay <vi...@anyware-tech.com> wrote:
>
> Xavier Hanin wrote:
> > Hi,
> >
> > I'm currently using wicketstuff-push to push events to a page and it
> > works
> > pretty well, but not well enough. Before trying to move to a comet based
> > implementation, I would like to improve the timer based
> > implementation. In
> > the current implementation you got as many AjaxTimer as you install
> > the push
> > on components on the same page. So if you have three components
> requiring
> > push, you will have three requests each x seconds, to poll for push
> > events
> > from the three components. This would be much more efficient if I had
> > only
> > one request polling for all push events sent by all components on the
> > page...
> >
> > Hence my first thought was to add the timer behavior to the page
> > instead of
> > the component, and verify that the same kind of behavior is not already
> > installed before installing a new one. The problem is that when I
> install
> > the behavior the component doesn't know its page. So I have to do
> > something
> > at this time, and then later when I know the page make sure that only
> one
> > behavior is actually rendered.
> >
> > I see two solutions to this problem:
> > - Add one timer behavior to each component (as today), and then when
> > rendering the component use the wasRendered/markRendered methods of
> > IHeaderResponse to render only one of them (using the isEnabled method
> to
> > disable it if another similar one has already been rendered). But then I
> > will have to update all the non rendered behaviors so that push events
> > sent
> > to them are actually sent to the only behavior which is rendered.
> > - Modify the API of the push service and ask to enable push on a page
> > before
> > actually using push on components on the page. This would actually
> > install a
> > unique timer behavior on the page. Then when installing push on a
> > component
> > I could simply add something which could be located by the unique
> > timer on
> > the page to collect all push events (maybe a disabled behavior)
> >
> > Now that I expose the two options I think I prefer the first one. But I
> > would like to gather feedback from experienced wicket developers to
> > see if
> > I'm not missing something or if you have better ideas about how to
> > implement
> > what I want.
>
> Hy Xavier,
>
> I've got an idea but I don't know if it will be convenient:
> TimerPushBehavior should not extends AjaxTimerBehavior.
> TimerPushBehavior could now do :
> - Adding a javascript(jsMain) in the header (using a static id - render
> once). This javascript can manage ajax timer on a specific callback url.
> - Each TimerPushBehavior registers its component id on the previous
> added javascript(jsMain)
> - When a callback is received by the first added behavior:
>     * get all id registered in jsMain (sent to the behavior as
> parameters of the callbackUrl)
>     * look for each child(server side) by they component id (IVisitor)
>     * look for TimerPushBehavior on each child
>     * call onTimer method on each TimerPushBehavior of each Child
>
> it is may be a little bit hacked but it can be a solution.
> WDYT?

Salut Vincent,

The idea to use a specific javascript to handle the timer is interesting.
Though ATM I've started implementing the first solution I suggested above,
and it now works pretty well like this. So I think I'll stick with that for
the moment, unless someone tell me there is a serious flaw in the approach I
used. You will also be able to review what I've done when I'll commit it on
wicketstuff-push, and revert or use another approach if there is a problem.

BTW I'm having an issue with the timer, but I think it's a bug in the
AbstractAjaxTimerBehavior implementation (I'll send another e-mail about
this).

Xavier

--
> Vincent
> >
> > Thanks,
> >
> > Xavier
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://incubator.apache.org/ivy/
http://www.xoocode.org/

Re: wicketstuff-push: centralizing requests

[Vincent Demay <vi...@anyware-tech.com>]

Xavier Hanin wrote:
> Hi,
>
> I'm currently using wicketstuff-push to push events to a page and it 
> works
> pretty well, but not well enough. Before trying to move to a comet based
> implementation, I would like to improve the timer based 
> implementation. In
> the current implementation you got as many AjaxTimer as you install 
> the push
> on components on the same page. So if you have three components requiring
> push, you will have three requests each x seconds, to poll for push 
> events
> from the three components. This would be much more efficient if I had 
> only
> one request polling for all push events sent by all components on the
> page...
>
> Hence my first thought was to add the timer behavior to the page 
> instead of
> the component, and verify that the same kind of behavior is not already
> installed before installing a new one. The problem is that when I install
> the behavior the component doesn't know its page. So I have to do 
> something
> at this time, and then later when I know the page make sure that only one
> behavior is actually rendered.
>
> I see two solutions to this problem:
> - Add one timer behavior to each component (as today), and then when
> rendering the component use the wasRendered/markRendered methods of
> IHeaderResponse to render only one of them (using the isEnabled method to
> disable it if another similar one has already been rendered). But then I
> will have to update all the non rendered behaviors so that push events 
> sent
> to them are actually sent to the only behavior which is rendered.
> - Modify the API of the push service and ask to enable push on a page 
> before
> actually using push on components on the page. This would actually 
> install a
> unique timer behavior on the page. Then when installing push on a 
> component
> I could simply add something which could be located by the unique 
> timer on
> the page to collect all push events (maybe a disabled behavior)
>
> Now that I expose the two options I think I prefer the first one. But I
> would like to gather feedback from experienced wicket developers to 
> see if
> I'm not missing something or if you have better ideas about how to 
> implement
> what I want.

Hy Xavier,

I've got an idea but I don't know if it will be convenient:
TimerPushBehavior should not extends AjaxTimerBehavior. 
TimerPushBehavior could now do :
 - Adding a javascript(jsMain) in the header (using a static id - render 
once). This javascript can manage ajax timer on a specific callback url.
 - Each TimerPushBehavior registers its component id on the previous 
added javascript(jsMain)
 - When a callback is received by the first added behavior:
    * get all id registered in jsMain (sent to the behavior as 
parameters of the callbackUrl)
    * look for each child(server side) by they component id (IVisitor)
    * look for TimerPushBehavior on each child
    * call onTimer method on each TimerPushBehavior of each Child

it is may be a little bit hacked but it can be a solution.
WDYT?

--
Vincent
>
> Thanks,
>
> Xavier