On 5/11/07, Vincent Demay <[EMAIL PROTECTED]> wrote:
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 ?
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/
