On Jan 8, 5:19=A0am, AAsk <AA2e...@[EMAIL PROTECTED]
> wrote:
> > I've searched the internet and found rather different-sounding
functiona=
lity described using this pair of buzzwords -> can you be more specific?
>
> I barely understand what this means so do not take what I say below as
> gospel: here it goes.
>
> With a client/server architecture, the server raises events to which
> the client reacts. For example, the server can raise an event when
> elements in an underlying database table has changed and the client
> may then proceed to refresh what information it shows on say, a form.
> To do this, the client refreshes 'everything' as it does not know what
> has changed.
>
> This approach is time-consuming and unviable for a browser-based
> application as it needs to be much more responsive - the hour glass in
> not a meaningful way of signalling a long process to the user.
>
> With subscribe/publish, the publisher is like the server with an
> important difference: the publisher does not know who the subscriber
> is or indeed how many of them there are. The subscriber is like the
> client only there may be several (or none). You might have a
> subscriber that listens only for changes, say, and signals that
> information to the application (GUI). Another example might be a
> subscriber that listens for signals to launch another process e.g.
> elements of an order may change that require parts of an invoice to be
> rebuilt.
>
> What client/server and subscribe/publish have in common is that the
> client (subscriber) reacts to events (serially) raised by the server
> (publisher); the important difference is that while the client/server
> architecture is synchronous (and 1:1, usually), the subscribe/publish
> architecture is not synchronous (and may be n:1, ie parallel).
>
> Hope this makes some sense.
This fits my understanding, but it is not very specific about
implementation. For a browser to be able to receive information which
is being "pushed", it must contain some code executing in the browser
(probably written in Javascript) which either implements a Web Server
and is listening for new connections (unlikely to work well behind
firewalls), or opens a socket to some service which occasionally sends
data down the wire. I don't see any reason why an APL server should
not be able to participate in a scheme like this.
This might be an interesting tool for someone to write and publish on
the APLWiki, to make a name for themselves as a web-savvy APLer :-).
I'm sure someone will need one soon...
Morten
|
