Why does it matter what caused the happening in the general case? If you
want to know what caused the event to happen, or what in that causes to
happen, ask separately.
>> - 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:
Oh yeah. I'm not trying to put any of these systems down by being so
flippant in my commentary. Just pointing out the variety - which is a
GoodThing.
>> - 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.
Then we clearly have differing definitions of "cool". IMHO, nothing about
printers will ever be cool.
>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.
Over TCP? Can't wait to see that reasoning!
>> - 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*
Well, ya see ... It all started with a wonderful concoction called the
"There's no fucking way there's alcohol in here" daiquiri. I'll leave the
rest to your imagination. P-)
>(Bonus points for sending it to fork instead of fork-noarchive like that
>pussycat Byars does... :)
Gee, and Tim really does look like this;
http://www.cs.caltech.edu/~adam/gifs/Tim.jpg
I figured that was touched-up or something ... 8-)
>> - 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.
There is? I thought the intent of building distributed events over RMI was
so that different socket implementations and protocols could be plugged in
as needed (via RMISocketFactory). By default, I would figure they'd use
JRMP. Am I wrong?
>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? :)
Yep, notify(). I really like the API, don't get me wrong. IMO, it's just
not tackling the most pressing problem (I was going to use the word
"avoid", but that's not true).
>> Sure, so maybe we can't have just one protocol for everybody,
>
>We can certainly have one protocol for Web notifications.
Depends what you mean by "Web notifications". But I'm skeptical anyhow.
>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.
Righto.
>> - 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.
So it'll get pruned down - via the magic of concensus making - to something
that many of those people won't use. FWIW, I'd rather see the effort fail
completely than to have that happen.
Yep, more skepticism.
>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.
Oh shit Adam.
MB
