wicket-contrib-push: question about "proxy" = "true"

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

Hey there,

I have a question about the data "proxy" set to "true" in CometdEvent: what
is it used for? Indeed I would like to get rid of CometdEvent, to make
implementation switch very easy, but I'm not sure if all cometd events
should always have this property set, or if only some should.

If they all should have this data, I can do what I've already proposed in my
patch (in a previous discussion on the user list). Otherwise the user will
have to keep in control of this, and if it's suited to cometd implementaiton
only, it will compromise my dream of transparent switching between
implementations :-)

TIA,

Xavier

-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

Re: wicket-contrib-push: question about "proxy" = "true"

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

On 5/11/07, Vincent Demay <vi...@anyware-tech.com> wrote:
>
> Xavier Hanin a écrit :
> > On 5/11/07, Vincent Demay <vi...@anyware-tech.com> wrote:
> >>
> >> Xavier Hanin a écrit :
> >> > On 5/11/07, Vincent Demay <vi...@anyware-tech.com> wrote:
> >> >>
> >> >> Hi
> >> >>
> >> >> Xavier Hanin a écrit :
> >> >> > Hey there,
> >> >> >
> >> >> > I have a question about the data "proxy" set to "true" in
> >> CometdEvent:
> >> >> > what
> >> >> > is it used for? Indeed I would like to get rid of CometdEvent, to
> >> make
> >> >> > implementation switch very easy, but I'm not sure if all cometd
> >> events
> >> >> > should always have this property set, or if only some should.
> >> >> If I well remember I added this "proxy" value in CometdEvent to
> >> know if
> >> >> an event has to be proxied by a behavior :
> >> >> If you have a look at CometdDefaultBehaviorTemplate.js, I check if
> >> >> proxy="true" before making a callback to the bahavior (var
> >> >> wcall=wicketAjaxGet('${url}' + addToUrl, function() { }, function()
> {
> >> >> });).
> >> >>
> >> >> The aim is to make a différence between an event/publisher/behavior
> >> >> architecture and a simple one(as in sharedForm) if cometd events are
> >> >> sent on the same channel.
> >> >
> >> >
> >> > OK, now that I've investigated a little more the code I understand
> how
> >> > it is
> >> > used.
> >> > The problem is that this is not really what I expected, because you
> >> don't
> >> > fully take advantage of comet: indeed each time an event is published
> >> > on the
> >> > channel, it is sent to the server with only the parameters, then the
> >> > client
> >> > send a regular ajax request to the server to get the actual UI
> >> > modifications. This means that you will have one connection for
> comet,
> >> > plus
> >> > one connection for each comet event, which doesn't scale very well.
> >> Yes exactly, With this way we can have different behaviors on
> differents
> >> pages according to the data coming from the event. But it is
> >> definitively not very scalable.
> >> >
> >> > I thought we might be able to send directly the same content of the
> >> > envelop
> >> > sent by wicket on the ajax call directly in the comet event data (the
> >> > envelop processed by Wicket.Ajax.Call.loadedCallback). In this case
> we
> >> > would
> >> > be able to use the comet connection only, which would be much more
> >> > scalable
> >> > IMO. This is not really what cometd is meant for, and it means this
> >> API
> >> > wouldn't be usable to send regular cometd events. So maybe I'm
> talking
> >> > about
> >> > another implementation of a different concept, which could co exist
> >> > with the
> >> > one you provided.
> >>
> >> I think it can be an other approach, sending directly in the event
> >> xmlFragment, javascript etc.. . but this kind of data are not very
> >> regular cometd events. CometD is supposed transport json, so data
> >> embedded in a serialized javascript object. The question is can we
> >> consider xmlFragment is a part of a json object value?
> >
> >
> > I think this should be possible with proper escaping. Al of that is text
> > after all.
> >
> > I see  An other problem : Using this approach means we know in the
> >> eventPublisher the page structure, so it is impossible to send event to
> >> different pages. And the event is directly very linked to the HMI.
> >
> >
> > Indeed, but what is the added value of sending events to several pages
> if
> > all pages then have to ask the server what to actually do.
> > I think your implementation is very nice to actually use cometd for
> > what its
> > is meant for, and I think preserving the CometdPublisher for instance
> > is a
> > must. It makes cometd publishing really easy. The
> > AbstractCometdBehavior is
> > also very nice to easily add client side reaction to regular cometd
> > events.
> > But the idea of using this as is with a proxy mechanism can be
> misleading
> > IMO (well, I was surprised to see how it works :-)). So I think with
> > proper
> > documentation we can provide two services: channel service, where we
> > publish
> > events on channels which can be listened to the client, and push service
> > (maybe this time it's really only pushing), for server initiated page
> > refresh only, using cometd as a transport mechanism only (properly
> > documented as doing so).
> >
> > Does it make sense?
> Yes ;)
> channel service will be Event->Client->Server->Client (Actual proxy)
> pushing service will be Event->Client (needs to specify a 'protocole' or
> a way to communicate via cometd json)
>
> Did I well understand ?


Yes, that's my vision. I don't know when I'll have time to work on the
pushing service  though, but the channel service is already working pretty
well.

Cheers,

Xavier

--
> Vincent
> >
> > Xavier
> >
> > WDYT?
> >>
> >> --
> >> Vincent
> >> >
> >> > WDYT?
> >> >
> >> >>
> >> >> > If they all should have this data, I can do what I've already
> >> proposed
> >> >> > in my
> >> >> > patch (in a previous discussion on the user list). Otherwise the
> >> user
> >> >> > will
> >> >> > have to keep in control of this, and if it's suited to cometd
> >> >> > implementaiton
> >> >> > only, it will compromise my dream of transparent switching between
> >> >> > implementations :-)
> >> >>
> >> >> If you think it is better to remove that in order to deal with all
> >> event
> >> >> in the channel, feel free to do it, but we need make user aware of
> >> that
> >> >> in javadoc. (a cometdEvent triggered by an event/publisher/behavior
> >> >> architecture can be intercept by a simple one in there are in the
> >> same
> >> >> channel).
> >> >
> >> >
> >> > Yes, this is because you post regular comet events, which I didn't
> >> > understand first. It also explain why the channel listener do not
> have
> >> > the
> >> > plain channel event, but only a map of strings. I think I'll need
> some
> >> > more
> >> > thoughts because I think we are trying to achieve to different
> things:
> >> > what
> >> > I need is server initiated refresh of the web page, using cometd
> >> > (could be
> >> > only comet actually I think) for the transport (or polling in
> degraded
> >> > mode). What we have for the moment is something which allows to
> easily
> >> > send
> >> > comet events, and on another hand easily react to these events on the
> >> > client
> >> > side to trigger a regular ajax call asking for page refresh. In your
> >> case
> >> > any one can send the simple comet event, with proxy set to true, it
> >> will
> >> > trigger the refresh with another call to the server. In my case
> >> only the
> >> > wicket app can send a comet event with the envelop attached: it's
> >> only a
> >> > transport mechanism, nothing else. That's why I think comet could be
> >> > enough,
> >> > no need for cometd. But I'm still not confortable enough with comet
> >> and
> >> > cometd to be sure of what I think.
> >> >
> >> > So for the moment I will commit my changes as is, but I'd welcome
> >> > opinion to
> >> > see if my use case and proposed implementation make sense.
> >> >
> >> > Xavier
> >> >
> >> > An other solution is to add it in timer implementation, even if it is
> >> >> useless, it's up to you ;)
> >> >>
> >> >> hope my explaination is clear ;)
> >> >>
> >> >> --
> >> >> Vincent
> >> >> >
> >> >> > TIA,
> >> >> >
> >> >> > Xavier
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

Re: wicket-contrib-push: question about "proxy" = "true"

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

Xavier Hanin a écrit :
> On 5/11/07, Vincent Demay <vi...@anyware-tech.com> wrote:
>>
>> Xavier Hanin a écrit :
>> > On 5/11/07, Vincent Demay <vi...@anyware-tech.com> wrote:
>> >>
>> >> Hi
>> >>
>> >> Xavier Hanin a écrit :
>> >> > Hey there,
>> >> >
>> >> > I have a question about the data "proxy" set to "true" in
>> CometdEvent:
>> >> > what
>> >> > is it used for? Indeed I would like to get rid of CometdEvent, to
>> make
>> >> > implementation switch very easy, but I'm not sure if all cometd
>> events
>> >> > should always have this property set, or if only some should.
>> >> If I well remember I added this "proxy" value in CometdEvent to 
>> know if
>> >> an event has to be proxied by a behavior :
>> >> If you have a look at CometdDefaultBehaviorTemplate.js, I check if
>> >> proxy="true" before making a callback to the bahavior (var
>> >> wcall=wicketAjaxGet('${url}' + addToUrl, function() { }, function() {
>> >> });).
>> >>
>> >> The aim is to make a différence between an event/publisher/behavior
>> >> architecture and a simple one(as in sharedForm) if cometd events are
>> >> sent on the same channel.
>> >
>> >
>> > OK, now that I've investigated a little more the code I understand how
>> > it is
>> > used.
>> > The problem is that this is not really what I expected, because you
>> don't
>> > fully take advantage of comet: indeed each time an event is published
>> > on the
>> > channel, it is sent to the server with only the parameters, then the
>> > client
>> > send a regular ajax request to the server to get the actual UI
>> > modifications. This means that you will have one connection for comet,
>> > plus
>> > one connection for each comet event, which doesn't scale very well.
>> Yes exactly, With this way we can have different behaviors on differents
>> pages according to the data coming from the event. But it is
>> definitively not very scalable.
>> >
>> > I thought we might be able to send directly the same content of the
>> > envelop
>> > sent by wicket on the ajax call directly in the comet event data (the
>> > envelop processed by Wicket.Ajax.Call.loadedCallback). In this case we
>> > would
>> > be able to use the comet connection only, which would be much more
>> > scalable
>> > IMO. This is not really what cometd is meant for, and it means this 
>> API
>> > wouldn't be usable to send regular cometd events. So maybe I'm talking
>> > about
>> > another implementation of a different concept, which could co exist
>> > with the
>> > one you provided.
>>
>> I think it can be an other approach, sending directly in the event
>> xmlFragment, javascript etc.. . but this kind of data are not very
>> regular cometd events. CometD is supposed transport json, so data
>> embedded in a serialized javascript object. The question is can we
>> consider xmlFragment is a part of a json object value?
>
>
> I think this should be possible with proper escaping. Al of that is text
> after all.
>
> I see  An other problem : Using this approach means we know in the
>> eventPublisher the page structure, so it is impossible to send event to
>> different pages. And the event is directly very linked to the HMI.
>
>
> Indeed, but what is the added value of sending events to several pages if
> all pages then have to ask the server what to actually do.
> I think your implementation is very nice to actually use cometd for 
> what its
> is meant for, and I think preserving the CometdPublisher for instance 
> is a
> must. It makes cometd publishing really easy. The 
> AbstractCometdBehavior is
> also very nice to easily add client side reaction to regular cometd 
> events.
> But the idea of using this as is with a proxy mechanism can be misleading
> IMO (well, I was surprised to see how it works :-)). So I think with 
> proper
> documentation we can provide two services: channel service, where we 
> publish
> events on channels which can be listened to the client, and push service
> (maybe this time it's really only pushing), for server initiated page
> refresh only, using cometd as a transport mechanism only (properly
> documented as doing so).
>
> Does it make sense?
Yes ;)
channel service will be Event->Client->Server->Client (Actual proxy)
pushing service will be Event->Client (needs to specify a 'protocole' or 
a way to communicate via cometd json)

Did I well understand ?

--
Vincent
>
> Xavier
>
> WDYT?
>>
>> -- 
>> Vincent
>> >
>> > WDYT?
>> >
>> >>
>> >> > If they all should have this data, I can do what I've already
>> proposed
>> >> > in my
>> >> > patch (in a previous discussion on the user list). Otherwise the 
>> user
>> >> > will
>> >> > have to keep in control of this, and if it's suited to cometd
>> >> > implementaiton
>> >> > only, it will compromise my dream of transparent switching between
>> >> > implementations :-)
>> >>
>> >> If you think it is better to remove that in order to deal with all
>> event
>> >> in the channel, feel free to do it, but we need make user aware of 
>> that
>> >> in javadoc. (a cometdEvent triggered by an event/publisher/behavior
>> >> architecture can be intercept by a simple one in there are in the 
>> same
>> >> channel).
>> >
>> >
>> > Yes, this is because you post regular comet events, which I didn't
>> > understand first. It also explain why the channel listener do not have
>> > the
>> > plain channel event, but only a map of strings. I think I'll need some
>> > more
>> > thoughts because I think we are trying to achieve to different things:
>> > what
>> > I need is server initiated refresh of the web page, using cometd
>> > (could be
>> > only comet actually I think) for the transport (or polling in degraded
>> > mode). What we have for the moment is something which allows to easily
>> > send
>> > comet events, and on another hand easily react to these events on the
>> > client
>> > side to trigger a regular ajax call asking for page refresh. In your
>> case
>> > any one can send the simple comet event, with proxy set to true, it 
>> will
>> > trigger the refresh with another call to the server. In my case 
>> only the
>> > wicket app can send a comet event with the envelop attached: it's 
>> only a
>> > transport mechanism, nothing else. That's why I think comet could be
>> > enough,
>> > no need for cometd. But I'm still not confortable enough with comet 
>> and
>> > cometd to be sure of what I think.
>> >
>> > So for the moment I will commit my changes as is, but I'd welcome
>> > opinion to
>> > see if my use case and proposed implementation make sense.
>> >
>> > Xavier
>> >
>> > An other solution is to add it in timer implementation, even if it is
>> >> useless, it's up to you ;)
>> >>
>> >> hope my explaination is clear ;)
>> >>
>> >> --
>> >> Vincent
>> >> >
>> >> > TIA,
>> >> >
>> >> > Xavier
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

Re: wicket-contrib-push: question about "proxy" = "true"

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

On 5/11/07, Vincent Demay <vi...@anyware-tech.com> wrote:
>
> Xavier Hanin a écrit :
> > On 5/11/07, Vincent Demay <vi...@anyware-tech.com> wrote:
> >>
> >> Hi
> >>
> >> Xavier Hanin a écrit :
> >> > Hey there,
> >> >
> >> > I have a question about the data "proxy" set to "true" in
> CometdEvent:
> >> > what
> >> > is it used for? Indeed I would like to get rid of CometdEvent, to
> make
> >> > implementation switch very easy, but I'm not sure if all cometd
> events
> >> > should always have this property set, or if only some should.
> >> If I well remember I added this "proxy" value in CometdEvent to know if
> >> an event has to be proxied by a behavior :
> >> If you have a look at CometdDefaultBehaviorTemplate.js, I check if
> >> proxy="true" before making a callback to the bahavior (var
> >> wcall=wicketAjaxGet('${url}' + addToUrl, function() { }, function() {
> >> });).
> >>
> >> The aim is to make a différence between an event/publisher/behavior
> >> architecture and a simple one(as in sharedForm) if cometd events are
> >> sent on the same channel.
> >
> >
> > OK, now that I've investigated a little more the code I understand how
> > it is
> > used.
> > The problem is that this is not really what I expected, because you
> don't
> > fully take advantage of comet: indeed each time an event is published
> > on the
> > channel, it is sent to the server with only the parameters, then the
> > client
> > send a regular ajax request to the server to get the actual UI
> > modifications. This means that you will have one connection for comet,
> > plus
> > one connection for each comet event, which doesn't scale very well.
> Yes exactly, With this way we can have different behaviors on differents
> pages according to the data coming from the event. But it is
> definitively not very scalable.
> >
> > I thought we might be able to send directly the same content of the
> > envelop
> > sent by wicket on the ajax call directly in the comet event data (the
> > envelop processed by Wicket.Ajax.Call.loadedCallback). In this case we
> > would
> > be able to use the comet connection only, which would be much more
> > scalable
> > IMO. This is not really what cometd is meant for, and it means this API
> > wouldn't be usable to send regular cometd events. So maybe I'm talking
> > about
> > another implementation of a different concept, which could co exist
> > with the
> > one you provided.
>
> I think it can be an other approach, sending directly in the event
> xmlFragment, javascript etc.. . but this kind of data are not very
> regular cometd events. CometD is supposed transport json, so data
> embedded in a serialized javascript object. The question is can we
> consider xmlFragment is a part of a json object value?


I think this should be possible with proper escaping. Al of that is text
after all.

I see  An other problem : Using this approach means we know in the
> eventPublisher the page structure, so it is impossible to send event to
> different pages. And the event is directly very linked to the HMI.


Indeed, but what is the added value of sending events to several pages if
all pages then have to ask the server what to actually do.
I think your implementation is very nice to actually use cometd for what its
is meant for, and I think preserving the CometdPublisher for instance is a
must. It makes cometd publishing really easy. The AbstractCometdBehavior is
also very nice to easily add client side reaction to regular cometd events.
But the idea of using this as is with a proxy mechanism can be misleading
IMO (well, I was surprised to see how it works :-)). So I think with proper
documentation we can provide two services: channel service, where we publish
events on channels which can be listened to the client, and push service
(maybe this time it's really only pushing), for server initiated page
refresh only, using cometd as a transport mechanism only (properly
documented as doing so).

Does it make sense?

Xavier

WDYT?
>
> --
> Vincent
> >
> > WDYT?
> >
> >>
> >> > If they all should have this data, I can do what I've already
> proposed
> >> > in my
> >> > patch (in a previous discussion on the user list). Otherwise the user
> >> > will
> >> > have to keep in control of this, and if it's suited to cometd
> >> > implementaiton
> >> > only, it will compromise my dream of transparent switching between
> >> > implementations :-)
> >>
> >> If you think it is better to remove that in order to deal with all
> event
> >> in the channel, feel free to do it, but we need make user aware of that
> >> in javadoc. (a cometdEvent triggered by an event/publisher/behavior
> >> architecture can be intercept by a simple one in there are in the same
> >> channel).
> >
> >
> > Yes, this is because you post regular comet events, which I didn't
> > understand first. It also explain why the channel listener do not have
> > the
> > plain channel event, but only a map of strings. I think I'll need some
> > more
> > thoughts because I think we are trying to achieve to different things:
> > what
> > I need is server initiated refresh of the web page, using cometd
> > (could be
> > only comet actually I think) for the transport (or polling in degraded
> > mode). What we have for the moment is something which allows to easily
> > send
> > comet events, and on another hand easily react to these events on the
> > client
> > side to trigger a regular ajax call asking for page refresh. In your
> case
> > any one can send the simple comet event, with proxy set to true, it will
> > trigger the refresh with another call to the server. In my case only the
> > wicket app can send a comet event with the envelop attached: it's only a
> > transport mechanism, nothing else. That's why I think comet could be
> > enough,
> > no need for cometd. But I'm still not confortable enough with comet and
> > cometd to be sure of what I think.
> >
> > So for the moment I will commit my changes as is, but I'd welcome
> > opinion to
> > see if my use case and proposed implementation make sense.
> >
> > Xavier
> >
> > An other solution is to add it in timer implementation, even if it is
> >> useless, it's up to you ;)
> >>
> >> hope my explaination is clear ;)
> >>
> >> --
> >> Vincent
> >> >
> >> > TIA,
> >> >
> >> > Xavier
> >> >
> >>
> >>
> >
> >
>
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

Re: wicket-contrib-push: question about "proxy" = "true"

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

Xavier Hanin a écrit :
> On 5/11/07, Vincent Demay <vi...@anyware-tech.com> wrote:
>>
>> Hi
>>
>> Xavier Hanin a écrit :
>> > Hey there,
>> >
>> > I have a question about the data "proxy" set to "true" in CometdEvent:
>> > what
>> > is it used for? Indeed I would like to get rid of CometdEvent, to make
>> > implementation switch very easy, but I'm not sure if all cometd events
>> > should always have this property set, or if only some should.
>> If I well remember I added this "proxy" value in CometdEvent to know if
>> an event has to be proxied by a behavior :
>> If you have a look at CometdDefaultBehaviorTemplate.js, I check if
>> proxy="true" before making a callback to the bahavior (var
>> wcall=wicketAjaxGet('${url}' + addToUrl, function() { }, function() {
>> });).
>>
>> The aim is to make a différence between an event/publisher/behavior
>> architecture and a simple one(as in sharedForm) if cometd events are
>> sent on the same channel.
>
>
> OK, now that I've investigated a little more the code I understand how 
> it is
> used.
> The problem is that this is not really what I expected, because you don't
> fully take advantage of comet: indeed each time an event is published 
> on the
> channel, it is sent to the server with only the parameters, then the 
> client
> send a regular ajax request to the server to get the actual UI
> modifications. This means that you will have one connection for comet, 
> plus
> one connection for each comet event, which doesn't scale very well.
Yes exactly, With this way we can have different behaviors on differents 
pages according to the data coming from the event. But it is 
definitively not very scalable.
>
> I thought we might be able to send directly the same content of the 
> envelop
> sent by wicket on the ajax call directly in the comet event data (the
> envelop processed by Wicket.Ajax.Call.loadedCallback). In this case we 
> would
> be able to use the comet connection only, which would be much more 
> scalable
> IMO. This is not really what cometd is meant for, and it means this API
> wouldn't be usable to send regular cometd events. So maybe I'm talking 
> about
> another implementation of a different concept, which could co exist 
> with the
> one you provided.

I think it can be an other approach, sending directly in the event 
xmlFragment, javascript etc.. . but this kind of data are not very 
regular cometd events. CometD is supposed transport json, so data 
embedded in a serialized javascript object. The question is can we 
consider xmlFragment is a part of a json object value?
I see  An other problem : Using this approach means we know in the 
eventPublisher the page structure, so it is impossible to send event to 
different pages. And the event is directly very linked to the HMI.

WDYT?

--
Vincent
>
> WDYT?
>
>>
>> > If they all should have this data, I can do what I've already proposed
>> > in my
>> > patch (in a previous discussion on the user list). Otherwise the user
>> > will
>> > have to keep in control of this, and if it's suited to cometd
>> > implementaiton
>> > only, it will compromise my dream of transparent switching between
>> > implementations :-)
>>
>> If you think it is better to remove that in order to deal with all event
>> in the channel, feel free to do it, but we need make user aware of that
>> in javadoc. (a cometdEvent triggered by an event/publisher/behavior
>> architecture can be intercept by a simple one in there are in the same
>> channel).
>
>
> Yes, this is because you post regular comet events, which I didn't
> understand first. It also explain why the channel listener do not have 
> the
> plain channel event, but only a map of strings. I think I'll need some 
> more
> thoughts because I think we are trying to achieve to different things: 
> what
> I need is server initiated refresh of the web page, using cometd 
> (could be
> only comet actually I think) for the transport (or polling in degraded
> mode). What we have for the moment is something which allows to easily 
> send
> comet events, and on another hand easily react to these events on the 
> client
> side to trigger a regular ajax call asking for page refresh. In your case
> any one can send the simple comet event, with proxy set to true, it will
> trigger the refresh with another call to the server. In my case only the
> wicket app can send a comet event with the envelop attached: it's only a
> transport mechanism, nothing else. That's why I think comet could be 
> enough,
> no need for cometd. But I'm still not confortable enough with comet and
> cometd to be sure of what I think.
>
> So for the moment I will commit my changes as is, but I'd welcome 
> opinion to
> see if my use case and proposed implementation make sense.
>
> Xavier
>
> An other solution is to add it in timer implementation, even if it is
>> useless, it's up to you ;)
>>
>> hope my explaination is clear ;)
>>
>> -- 
>> Vincent
>> >
>> > TIA,
>> >
>> > Xavier
>> >
>>
>>
>
>

Re: wicket-contrib-push: question about "proxy" = "true"

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

On 5/11/07, Vincent Demay <vi...@anyware-tech.com> wrote:
>
> Hi
>
> Xavier Hanin a écrit :
> > Hey there,
> >
> > I have a question about the data "proxy" set to "true" in CometdEvent:
> > what
> > is it used for? Indeed I would like to get rid of CometdEvent, to make
> > implementation switch very easy, but I'm not sure if all cometd events
> > should always have this property set, or if only some should.
> If I well remember I added this "proxy" value in CometdEvent to know if
> an event has to be proxied by a behavior :
> If you have a look at CometdDefaultBehaviorTemplate.js, I check if
> proxy="true" before making a callback to the bahavior (var
> wcall=wicketAjaxGet('${url}' + addToUrl, function() { }, function() {
> });).
>
> The aim is to make a différence between an event/publisher/behavior
> architecture and a simple one(as in sharedForm) if cometd events are
> sent on the same channel.


OK, now that I've investigated a little more the code I understand how it is
used.
The problem is that this is not really what I expected, because you don't
fully take advantage of comet: indeed each time an event is published on the
channel, it is sent to the server with only the parameters, then the client
send a regular ajax request to the server to get the actual UI
modifications. This means that you will have one connection for comet, plus
one connection for each comet event, which doesn't scale very well.

I thought we might be able to send directly the same content of the envelop
sent by wicket on the ajax call directly in the comet event data (the
envelop processed by Wicket.Ajax.Call.loadedCallback). In this case we would
be able to use the comet connection only, which would be much more scalable
IMO. This is not really what cometd is meant for, and it means this API
wouldn't be usable to send regular cometd events. So maybe I'm talking about
another implementation of a different concept, which could co exist with the
one you provided.

WDYT?

>
> > If they all should have this data, I can do what I've already proposed
> > in my
> > patch (in a previous discussion on the user list). Otherwise the user
> > will
> > have to keep in control of this, and if it's suited to cometd
> > implementaiton
> > only, it will compromise my dream of transparent switching between
> > implementations :-)
>
> If you think it is better to remove that in order to deal with all event
> in the channel, feel free to do it, but we need make user aware of that
> in javadoc. (a cometdEvent triggered by an event/publisher/behavior
> architecture can be intercept by a simple one in there are in the same
> channel).


Yes, this is because you post regular comet events, which I didn't
understand first. It also explain why the channel listener do not have the
plain channel event, but only a map of strings. I think I'll need some more
thoughts because I think we are trying to achieve to different things: what
I need is server initiated refresh of the web page, using cometd (could be
only comet actually I think) for the transport (or polling in degraded
mode). What we have for the moment is something which allows to easily send
comet events, and on another hand easily react to these events on the client
side to trigger a regular ajax call asking for page refresh. In your case
any one can send the simple comet event, with proxy set to true, it will
trigger the refresh with another call to the server. In my case only the
wicket app can send a comet event with the envelop attached: it's only a
transport mechanism, nothing else. That's why I think comet could be enough,
no need for cometd. But I'm still not confortable enough with comet and
cometd to be sure of what I think.

So for the moment I will commit my changes as is, but I'd welcome opinion to
see if my use case and proposed implementation make sense.

Xavier

An other solution is to add it in timer implementation, even if it is
> useless, it's up to you ;)
>
> hope my explaination is clear ;)
>
> --
> Vincent
> >
> > TIA,
> >
> > Xavier
> >
>
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

Re: wicket-contrib-push: question about "proxy" = "true"

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

Hi

Xavier Hanin a écrit :
> Hey there,
>
> I have a question about the data "proxy" set to "true" in CometdEvent: 
> what
> is it used for? Indeed I would like to get rid of CometdEvent, to make
> implementation switch very easy, but I'm not sure if all cometd events
> should always have this property set, or if only some should.
If I well remember I added this "proxy" value in CometdEvent to know if 
an event has to be proxied by a behavior :
If you have a look at CometdDefaultBehaviorTemplate.js, I check if 
proxy="true" before making a callback to the bahavior (var 
wcall=wicketAjaxGet('${url}' + addToUrl, function() { }, function() { });).

The aim is to make a différence between an event/publisher/behavior 
architecture and a simple one(as in sharedForm) if cometd events are 
sent on the same channel.

>
> If they all should have this data, I can do what I've already proposed 
> in my
> patch (in a previous discussion on the user list). Otherwise the user 
> will
> have to keep in control of this, and if it's suited to cometd 
> implementaiton
> only, it will compromise my dream of transparent switching between
> implementations :-)

If you think it is better to remove that in order to deal with all event 
in the channel, feel free to do it, but we need make user aware of that 
in javadoc. (a cometdEvent triggered by an event/publisher/behavior 
architecture can be intercept by a simple one in there are in the same 
channel).

An other solution is to add it in timer implementation, even if it is 
useless, it's up to you ;)

hope my explaination is clear ;)

--
Vincent
>
> TIA,
>
> Xavier
>