I think Jim and Rohit are writing the official report before the Chicago
IETF in 2 weeks.
> - an event is "the effect of the termination of an invocation of an
> operation on some object of interest"? Er, really? I prefer Webster -
> "a noteworthy happening".
Webster's is a bad definition because it tells you nothing about
what caused the happening, what the happening actually is, and what the
happening in turn causes to happen. It's not happenstance.
> - Hey, look at all these *other* event notification systems! AKA, "Hmm,
> maybe if I talk a mile-a-minute, people will be impressed!" 8-)
> http://www.ics.uci.edu/IRUS/wisen/abstracts/abs_rifkin.html
A better URL for that talk includes the slides:
http://www.cs.caltech.edu/~adam/isen/evolution-of-isens/
> - no, no, look at *my* event notification system!
> http://www.ics.uci.edu/IRUS/wisen/presentations/Low/
Actually, Keryx is worth a second look. It's got lots of useful
features as a Java-based event notification system:
> - how does one define "on-line" for a printer, anyhow? This has got to
> be the furthest thing from a "killer app" ever. Ick.
> http://www.ics.uci.edu/IRUS/wisen/presentations/Isaacson/
On the contrary, printer notifications will probably be one of the first
cool applications that falls out of a unified notification effort.
> - XML + HTTP-extensions. Too simplistic, but looks ok if that's what
> you want. http://www.ics.uci.edu/IRUS/wisen/presentations/Cohen/
Simplicity is a good thing in GENA's case: it means people are more
likely to implement it and use it.
I happen to think it is desirable to have event notification services
for the Web over HTTP. In fact, Rohit and I are writing up a position
statement of that as we speak.
> - magically awake 15 mins before it starts, on 2.5 hours sleep. Don't
> wake Rohit - not sure why - could have something to do with said 2.5
> hours sleep. Oops.
There were many factors at play that evening. Rohit's life is way more
complicated than casual observation would lead one to believe.
> - sex slave, Catalina island, Rohit's love life, UCI cops, "If he dies
> tonight, I'm ok with that", coming across as "the quiet guy" once again
> (damn)
So, you want to not be "the quiet guy"? *evil grin* Then share with us
what happened in between your first sex partner and your most recent sex
partner... *wink*
(Bonus points for sending it to fork instead of fork-noarchive like that
pussycat Byars does... :)
Wonder why there's been so much posting about sex lately.
http://xent.ics.uci.edu/FoRK-archive/august98/0026.html
http://xent.ics.uci.edu/FoRK-archive/august98/0078.html
http://xent.ics.uci.edu/FoRK-archive/august98/0085.html
http://xent.ics.uci.edu/FoRK-archive/august98/0126.html
http://xent.ics.uci.edu/FoRK-archive/august98/0173.html
http://xent.ics.uci.edu/FoRK-archive/august98/0185.html
http://xent.ics.uci.edu/FoRK-archive/august98/0188.html
http://xent.ics.uci.edu/FoRK-archive/august98/0229.html
Maybe because August is the hottest month?
Or maybe because it's the cruelest month?
> - Waldo presents Java Distributed Events API (released with Jini). Ok,
> but where's the protocol?
There's a protocol there, it's just in Sun's best interest to keep it
proprietary.
I html'ized my notes from his slides from his WISEN talk; they are at
http://www.cs.caltech.edu/~adam/isen/papers/waldo.html
and the full spec for Sun's distributed events (including some
information about the protocol) is at
http://java.sun.com/products/javaspaces/specs/ev.ps
I do believe a generic event notification protocol will have to avoid
being Java-specific, but Waldo's done an excellent job of simplifying
the API. (What is there, one method call in total? :)
> Sure, so maybe we can't have just one protocol for everybody,
We can certainly have one protocol for Web notifications.
> but maybe we can have one that can do 80% of what we need it to -
> don't you think Jim? Even 50% would be quite an accomplishment.
> Gosh, look what kind of event notifications have been done on top of
> just SMTP.
Sure, but SMTP has a lot of other baggage you don't want in a Web
notification protocol.
> - damnit, reliability is *not* a core requirement of the protocol.
> "Reliability" in a distributed environment is an app-level concern.
> Doesn't anybody keep up with this stuff? <sigh>
> http://www.ics.uci.edu/IRUS/wisen/presentations/Summary-Reqts/
Reliable notifications will be a requirement for some applications.
Therefore, a notification protocol should have hooks for reliability
when needed, incurring the associated performance penalty.
> - IETF ISEN BOF - should be interesting. May not be ready for
> standardization, but the cost of not doing it could be too high. Sounds
> like we're ripe for a 5 year standardization effort!! 8-O
No way. Lots of people want (heck, *need*) this one done quickly.
Oh, one more thing: this is no longer my PhD topic. Not that that
matters to anyone but me. I just wanted to shout my barbaric yawp from
the rooftops of the FoRK.
----
adam@cs.caltech.edu
There are more books to read, more music to play, more words to write,
and more places to see...
-- Retirement Notification, Kenneth Ashworth, Texas Higher Education
Commissioner for 21 Years