W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

Re: WebDAV Invalidation (Was Re: Allow: header and supported methods)

From: Eckhard Kantz <deltav@wegalink.de>
Date: Thu, 30 Aug 2001 12:07:42 +0200
Message-ID: <007001c1313b$9d195880$be00a8c0@wegalink.pro>
To: <ietf-dav-versioning@w3.org>
[Jösh Cohen wrote]
> ...wondering what people think about including the ability
> to subscribe to events on resources?

A similar idea came to my mind, too. However, maintaining events on a resource basis may easily
become too much work in a real-world scenario.Let's look at a non-technical example where event
processing takes place and where some ideas may be derived from. An avarage day in an office may
serve as such an example:

In the morning someone enters the rooms of the office where he is employed. From now on he will be
exposed to event notifications in the office:
- arrival/leaving of other team members
- telephone calls from customers
- someone starting/finishing some piece of work
- Looking at the screen of somebody else will provide to very high frequent event notifications
about where the mouse is pointing to and which keys are pressed in what sequence by the co-worker
- ...
Leaving the office will normally prevent from receiving anymore events (given the mobile was
switched off :)

In a technical sense an equivalent of an office could play the role of an event distribution point.
Many resources,e.g. all documents belonging to one project, could be asked somehow to deliver events
to such a distribution point, e.g. a virtual office.

A person being interested in receiving events from a certain project that is maintained by a virtual
office could then subscribe to it and would receive from then on events that are delivered to that
virtual office. Subscription to a virtual office would be the equivalent of entering an office in
the morning and to unsubcribe from a virtual office would be the equivalent of leaving the office in
the evening respectively.

It sounds easy but for sure it isn't. Since it is commonly known that _every_ system can be pulled
down by overloading it with events some precautions have to be build in. For example, if someone has
to respond to multiple phone calls per hour it will be hard to focus on concentrated work at the
same time. In the opposite, someone in a call center will most likely not have any problems to deal
with a very high number of phone calls per hour. So it seems that the receipient of events should be
able to maintain a filter that prevents from receiving unwanted and maybe too many events.

Actually, there would be at least two sets of filter rules to be maintained, one set of rules that
apply to the virtual office and which will decide upon what events will be send from resources to
the virtual office for distribution. A second set of filter rules would limit the number of
available events further in order to get only the desired ones to the receipient. There may be still
other sets of rules that deal for example with security and authorization issues (not everyone maybe
allowed to receive all events).

Does this approach sounds reasonable?

> Does this sound at all like something the group
> would be interested in taking a closer look at ?

I can vote only for myself, however, at the moment I am looking for all kinds of ideas that could
help to get closer to an event model that would work reasonably well in Internet scale. To give some
more background, the event model should work for huge document repositories as well as for automatic
systems that are connected over the internet. Particularly it should allow to connect radio
astronomy stations that are located around the globe and to control them remotely. Those stations
have the need to get synchronized with regard to their pointing positions, receiver frequencies and
other observation parameters as well as to deliver notifications dependent on the received signals
to mention only some of the requirements.

Received on Thursday, 30 August 2001 06:08:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC