This is the notification effort I mentioned at the Washington DC
meetings last week. I have not yet spoken with the author, but
intend to stay on top of this effort to determine the viability
of the BLIP approach, as well as gauge how successful it will
be in the general marketplace.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
--------------192FA4DB6BD7153128EDBBD1
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by uscore.underscore.com (8.8.4/8.7.2) with ESMTP id RAA13599; Sat, 23 May 1998 17:20:59 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA07030; Sat, 23 May 1998 17:20:59 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Sat, 23 May 1998 17:19:42 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA06920 for ipp-outgoing; Sat, 23 May 1998 17:18:04 -0400 (EDT)
Message-ID: <199805232117.RAA26749@rodney.concentric.net>
Comments: Authenticated sender is <mattj%blip.org@pop3.blip.org>
From: "Matt Jensen" <mattj@blip.org>
To: notification@makelist.com
Date: Sat, 23 May 1998 14:18:56 +0000
MIME-Version: 1.0
Content-transfer-encoding: 7BIT
Subject: IPP> Notification mailing list - A unified effort
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.42a)
Sender: owner-ipp@pwg.org
Content-Type: text/plain; charset=US-ASCII
We're announcing the Notification mailing list to discuss ways to
unify Internet notification efforts.
This message is being blind-cc'd to mailing lists and individuals who
have discussed a need for a quick notification service. We want to
quickly know when, for example...
* A friend comes online. (RVP/Buddy List group)
* A document has finished printing. (Internet Printing Protocol group)
* Someone releases their hold on a document I'm waiting to edit.
(WebDAV group)
There are also other uses for quick notification (pushing news,
linking distributed systems, remote monitoring, etc.) which do not
currently have mailing lists or working groups of their own.
It is becoming clear to many people that there is a growing need for a
UNIFIED EFFORT to provide a single notification protocol/service that
all of these groups could use, rather than have each group create
overlapping solutions.
A new mailing list has been set up for this discussion at
notification@makelist.com. To subscribe, send an empty message to
notification-subscribe@makelist.com . An archive is available at
http://www.findmail.com/list/notification/ .
This mailing list is for:
1. Discussing requirements of a single notification system which would
work for different groups. 2. Defining an open protocol which meets
those requirements.
We hope you will join this list, even if (or especially if) you are
not sure this unified approach is right for your notification needs.
If you discuss notification in other lists, we would appreciate you
cc'ing the Notification list, too. Below we discuss the rationale for
this effort.
The benefits of a such a single service include:
* Avoids duplication of effort. Invent the wheel only once.
* Avoids extra administrative burden. Issues of bandwidth, servers,
accounts, passwords, and integration are handled only once, by the
notification server. The alternative is that every other service
(buddy lists, printers...) duplicates those demands by doing their own
notification.
* Speeds standards design. If your working group can hand off the
notification issue, you can finish the rest of your design faster.
* Provides inter-group leverage. Without a single standard, it's
difficult for messages in these different contexts to be integrated.
For example, you might want a document to be printed as soon as a user
finishes editing it. Or a security sensor alert could be sent to your
Instant Message software, and also logged in a database somewhere
else.
The possible drawbacks are:
* A separate notification effort might provide fewer features than a
group needs, or burden them with unneeded features.
* It might slow a group down to have to wait for the results of the
notification group.
We believe these are valid concerns, but we also believe at this point
that:
1. The dangers of feature mismatch are not significant right now. The
different applications seem to require very similar sets of
requirements. As for overspecifying, note that with a separate
notification approach, you could end up with LESS work because you
wouldn't have to implement notifications in your system; you could use
someone else's compliant notification service through an API.
2. We think the notification problem can be solved faster with a
specialized effort. Some of us who have been focused on the issue for
a long time have worked through problems that others are only starting
to discover.
3. In the near future, people are going to demand more integration
between these groups. It would be easier to have everyone use the
same tools early on than to stitch everyone together after wide
deployment of different tools.
We want to hear your opinions on these matters. Thanks for your time.
-Matt Jensen
BLIP Project Director
mattj@blip.org
[Full disclosure: Our volunteer group, BLIP.org, has been developing
an open protocol for notification over the last year. You can check
out what we have so far at www.blip.org.]
--------------192FA4DB6BD7153128EDBBD1--