Event based web-page

[Bram Stolk]

Hello,


Most web pages are driven by events from the browser client.
If you want to send data triggered by events server-side, you can use
server-push technology (which seems to originate from netscape, and my opera
webclient doesn't work with this).

Now... my question:

How can I have a web page, whose content is changed on events that may
be generated on *BOTH* (server and client) sides.

So the server may decide to update the content, and the client may decide
to update the content. If any of the two decides to do this, the other
should be notified.

I can imagine that I could use a Java app client side, to achieve this,
but Java is no longer standard on windows machines. Can I manage to do
this without java? Similarly, javascript is often disabled for security
reasons, so that looks to be a no-go as well.

I would like a solution that works with vanilla clients. Server side, I
can do pretty much anything, thanks to Python.

Bram

--
------------------------------------------------------------------------------
Bram Stolk, VR Engineer.
SARA Academic Computing Services Amsterdam, PO Box 94613, 1090 GP AMSTERDAM
email: bram@nospam.sar a.nl Phone +31-20-5923059 Fax +31-20-6683167

"For the costs of subsidized agriculture in the EU, we can have all 56 million
European cows fly around the world. First Class." - J. Norberg
------------------------------------------------------------------------------

[Werner Partner]

Re: Event based web-page

Bram Stolk schrieb:
[color=blue]
> Hello,
>
>
> Most web pages are driven by events from the browser client.
> If you want to send data triggered by events server-side, you can use
> server-push technology (which seems to originate from netscape, and my opera
> webclient doesn't work with this).
>
> Now... my question:
>
> How can I have a web page, whose content is changed on events that may
> be generated on *BOTH* (server and client) sides.
>
> So the server may decide to update the content, and the client may decide
> to update the content. If any of the two decides to do this, the other
> should be notified.
>
> I can imagine that I could use a Java app client side, to achieve this,
> but Java is no longer standard on windows machines. Can I manage to do
> this without java? Similarly, javascript is often disabled for security
> reasons, so that looks to be a no-go as well.
>[/color]

In my opinion you cannot use java because it works only on client's
side, but you can use PHP:

If I understood you right, you want to have this:

Someone (server or client) wants to put some content into a given space:

PHP Code reads the text which is given (e.g. by client) and builds a new
document and overwrites the old document by the new on. Header an footer
of the document are constant, only the given content must be filled in
the given place.

Werner

--
-----------------------------------------------------------
Werner Partner * Tel +49 2366 886606 * Fax: 886608
mailto:kairos@s onoptikon.de * http://www.sonoptikon.de
hören Sie Klassik: http://www.drmk.ch/

[Bram Stolk]

Re: Event based web-page

On Thu, 29 Apr 2004 11:02:10 +0200
Werner Partner <kairos@sonopti kon.de> wrote:
[color=blue]
> Bram Stolk schrieb:
> [color=green]
> > Hello,
> >
> >
> > Most web pages are driven by events from the browser client.
> > If you want to send data triggered by events server-side, you can use
> > server-push technology (which seems to originate from netscape, and my opera
> > webclient doesn't work with this).
> >
> > Now... my question:
> >
> > How can I have a web page, whose content is changed on events that may
> > be generated on *BOTH* (server and client) sides.
> >
> > So the server may decide to update the content, and the client may decide
> > to update the content. If any of the two decides to do this, the other
> > should be notified.
> >
> > I can imagine that I could use a Java app client side, to achieve this,
> > but Java is no longer standard on windows machines. Can I manage to do
> > this without java? Similarly, javascript is often disabled for security
> > reasons, so that looks to be a no-go as well.
> > [/color]
>
> In my opinion you cannot use java because it works only on client's
> side, but you can use PHP:
>
> If I understood you right, you want to have this:
>
> Someone (server or client) wants to put some content into a given space:
>
> PHP Code reads the text which is given (e.g. by client) and builds a new
> document and overwrites the old document by the new on. Header an footer
> of the document are constant, only the given content must be filled in
> the given place.[/color]

No, this is not what I want to do. My specific task:

My server has tabular data.
This should be presented as a table in the client browser.

Then, either the user can change the data, (server to be updated).
Or the server changes the data (client to be updated).

This describes the task I am trying to do with one minor detail:
Instead of actual data-changes, I want to merely communicate
changes in sub-selections of this data. (Either server or client
can change which rows in the table are selected, and which are not.
If one side changes active selection, the other must be notified).

Bram
[color=blue]
>
> Werner
>
> --
> -----------------------------------------------------------
> Werner Partner * Tel +49 2366 886606 * Fax: 886608
> mailto:kairos@s onoptikon.de * http://www.sonoptikon.de
> hören Sie Klassik: http://www.drmk.ch/[/color]


--
------------------------------------------------------------------------------
Bram Stolk, VR Engineer.
SARA Academic Computing Services Amsterdam, PO Box 94613, 1090 GP AMSTERDAM
email: bram@nospam.sar a.nl Phone +31-20-5923059 Fax +31-20-6683167

"For the costs of subsidized agriculture in the EU, we can have all 56 million
European cows fly around the world. First Class." - J. Norberg
------------------------------------------------------------------------------

[Alan J. Flavell]

Re: Event based web-page

On Thu, 29 Apr 2004, Bram Stolk wrote:
[color=blue]
> Most web pages are driven by events from the browser client.[/color]

That's the paradigm upon which the WWW, and its favourite protocol
HTTP, were built. Anything else will turn out to be cruel and
unnatural, from that point of view. So you'd be better looking for -
either a different protocol, one that's designed for this kind of
interaction - or some other way of engineering your activities within
the scope of HTTP.

Incidentally, this doesn't seem to have very much with authoring HTML
for the WWW.[1]
[color=blue]
> If you want to send data triggered by events server-side, you can use
> server-push technology (which seems to originate from netscape, and my opera
> webclient doesn't work with this).[/color]

Server-push never really "took off"; I'd interpret it as being simply
too far away from what the design of HTTP protocol intended.
[color=blue]
> Now... my question:
>
> How can I have a web page, whose content is changed on events that may
> be generated on *BOTH* (server and client) sides.[/color]

java applets are quite good at this. Or in some circumstances,
intermittent "client pull" (meta...refresh - in principle
non-standard, but widely implemented) can be used to get fresh data
from the server, reflecting any changes that occurred meantime.
[color=blue]
> I can imagine that I could use a Java app client side, to achieve this,
> but Java is no longer standard on windows machines. Can I manage to do
> this without java?[/color]

If you want something to work with IE, you possibly want to look at
a dual-mode implementation that uses java for WWW browsers, and
active-X for the proprietary operating-system component.

Well, you could insist that those who want to use IE must follow the
instructions to install java. Or use another browser. After all,
extras are supposed to be optional. It's their choice whether they
want to get the optional functionality. (See vrvs.org for a somewhat
elaborate example of this kind of thing in practice).
[color=blue]
> Similarly, javascript is often disabled for security
> reasons, so that looks to be a no-go as well.[/color]

Hmmm, try giving this a bit more thought. The reason that many folks
disable js is to prevent unwanted server-side interference with their
WWW experience (whether for security reasons or just plain nuisance
value). If you _want_ interaction, and _they_ also want interaction,
then there has to be a bit of co-operation on both sides.
[color=blue]
> I would like a solution that works with vanilla clients.[/color]

On that point, you're asking too much, IMHO. The basic WWW paradigm
is that the client sends a request to a server - the server responds -
end of transaction. All else is extra. There's nothing wrong with
those extras (without them, for example, they couldn't have
implemented vrvs.org), but they all imply implementation extras and
user consent, which are not necessarily present in the "vanilla" WWW
situation.

[1] "Go not to usenet for advice, for they will say both yes and no,
and try another newsgroup" - (attribution lost, sorry)

[Bram Stolk]

Re: Event based web-page

On Thu, 29 Apr 2004 10:23:44 +0100
"Alan J. Flavell" <flavell@ph.gla .ac.uk> wrote:
[color=blue][color=green]
> > I would like a solution that works with vanilla clients.[/color]
>
> On that point, you're asking too much, IMHO. The basic WWW paradigm
> is that the client sends a request to a server - the server responds -
> end of transaction. All else is extra. There's nothing wrong with
> those extras (without them, for example, they couldn't have
> implemented vrvs.org), but they all imply implementation extras and
> user consent, which are not necessarily present in the "vanilla" WWW
> situation.[/color]

Alan,

Thanks for your comments.
I've been reading up all day on DCOM, SOAP, XML-RPC, SERVER-PUSH,
CORBA, etc. But nothing seems to fit the bill.

My current assessment is that if somehow, browsers would be able
to both send and receive RPCs, I could synchronize the data on both
sides on arbitrary events.

Bram (I am aware this is not strict comp.infosystem s.www.auth.html stuff,
but I dit not find a more appropriate newsgroup).

--
------------------------------------------------------------------------------
Bram Stolk, VR Engineer.
SARA Academic Computing Services Amsterdam, PO Box 94613, 1090 GP AMSTERDAM
email: bram@nospam.sar a.nl Phone +31-20-5923059 Fax +31-20-6683167

"For the costs of subsidized agriculture in the EU, we can have all 56 million
European cows fly around the world. First Class." - J. Norberg
------------------------------------------------------------------------------

[Alan J. Flavell]

Re: Event based web-page

On Thu, 29 Apr 2004, Bram Stolk wrote:

By the way, I deduce that you are involved with the Cave at SARA, yes?
I saw that demonstrated, a little while back, it was very impressive
(I almost got sea-sick at one point...)
[color=blue]
> On Thu, 29 Apr 2004 10:23:44 +0100
> "Alan J. Flavell" <flavell@ph.gla .ac.uk> wrote:
>[color=green][color=darkred]
> > > I would like a solution that works with vanilla clients.[/color]
> >
> > On that point, you're asking too much, IMHO. The basic WWW paradigm
> > is that the client sends a request to a server - the server responds -
> > end of transaction. All else is extra. There's nothing wrong with
> > those extras (without them, for example, they couldn't have
> > implemented vrvs.org), but they all imply implementation extras and
> > user consent, which are not necessarily present in the "vanilla" WWW
> > situation.[/color]
>
> My current assessment is that if somehow, browsers would be able
> to both send and receive RPCs, I could synchronize the data on both
> sides on arbitrary events.[/color]

At risk of stating the obvious,

http://java.sun.com/docs/books/tutorial/networking/sockets/definition.html

As I said before, HTTP protocol does not really seem suitable, in
itself, for this purpose, since its paradigm is designed to be a
relatively short request/response relationship between client and
server, with interactions initiated from the client side; rather than
long-term persisting communications, in which either side is able to
initiate some action, as you clearly want.
[color=blue]
> (I am aware this is not strict comp.infosystem s.www.auth.html stuff,
> but I dit not find a more appropriate newsgroup).[/color]

Yes, I recognise the problem. Once you raise this question on, say, a
Java language group, it already pre-supposes that you selected Java as
your solution technology. I don't know the right place to ask about
choosing an appropriate technology before you reach that point.

But whatever software you use at each end, you need some kind of
duplex network path between them, and a protocol for handling the
interaction. It could be a TCP connection, or it could just be
exchange of datagrams (but probably TCP is more congenial to
firewalls, so you may want to consider that aspect, as well as
guaranteeing reliable data). If you intend the server to cause
incremental changes to some HTML on the client, maybe you [also] need
Javascript at the client end, modifying the document (DOM). But I am
only "thinking aloud" and taking sideways looks at other applications
which do something similar (e.g the vrvs.org and their "chat window
applet" for example)

One practical issue did strike me as I was reading your description,
though: it appears that in your application, the document can be
edited from both sides at the same time. This sounds to me like a
potentially frustrating and error-prone situation. I remember using
the mbone nte (network text editor), which permitted multiple users to
edit the same document simultaneously. It needed considerable
discipline from the participants, if the result was not to be chaos.
( http://www-mice.cs.ucl.ac.uk/multimedia/software/nte/ if you want to
know what I mean, but in this discussion I'm stressing more the principle
than the details of this one specific application.)

Perhaps it would be better to include an explicit procedure for
handing over the control.