Benji York wrote:

> Balazs Ree wrote:
>> However there is nothing that would keep away a server to be "aware" of
>> currently open pages and be able to send notifications to them. This
>> would
>> also require server support for registering open connections. This
>> pattern
>> might even turn out to be so useful, that we will see it generally
>> supported in five years from now.
>> On the other hand the same functionality can also be accomplished by
>> "traditional" AJAX polling. So at the moment, when talking about
>> AJAX, one
>> usually speaks of the currently implementable "server pull"
>> approach. 
> Something I'd like to play with would be an integration of Zope 3
> events and MochiKit's signals.  Perhaps queuing events on the server
> and the client could periodically retrieve them.  The client could
> also queue events or send them immediately to the server.

In the same area, I wanted to keep a track of request status on the
server when i upload a file, that the client can query asynchronously.
I think it's the same pattern:

1/ the page provocates a server call, that generates events in your
case, uploads in mine (this could be events as well)
2/ the client JS calls the server to get feedback on some kind of APIs,
to know what's happening (uploading status, event queue, etc..)
3/ the client JS can refresh the page upon these infos

The only issue I can think of is security. Maybe we could make sure that
the client that calls for the infos is
the same one that has provocated the server event.

Anyway, we could probably set up a dedicated space on the server memory
to keep track of this infos, and provide
APIs to access it.  This space would keep track of:

- live requests status
- a dedicated queue for a certain class of events

that could be a dedicated package maybe, but it has to add hooks into
the publisher to keep track
on request data uploadings


Zope3-dev mailing list

Reply via email to