Xavier Hanin a écrit :
On 5/11/07, Vincent Demay <[EMAIL PROTECTED]> wrote:
Xavier Hanin a écrit :
> On 5/11/07, Vincent Demay <[EMAIL PROTECTED]> 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
>> >
>>
>>
>
>
