http://xent.ics.uci.edu/FoRK-archive/apr98/0445.html
demonstrated that he's thought about this a lot more than I have...
The skinny: I agree with you Roy, that what we really want is a single
generic API for subscribing to notifiers and receiving events (with
hooks for aggregation, filtering, forwarding, ...) in which the user can
customize message characteristics such as message size and performance.
> >My intuition is that if we could unify the API for the event models at
> >several different layers of the application stack -- from the way the
> >GUI sends event to "documents", to how documents send events among the
> >components (and scripts) embedded within those documents, to how the
> >components in documents subscribe to (and notify) the components and
> >scripts in other documents across the Internet -- well, then we'd have
> >something truly powerful.
> Er, well, you'd either have a very big API or a very generic API.
Hopefully the latter.
> I'm a big believer in generic APIs for Internet-scale messaging.
Same here.
> HTTP, for example, is just a very generic API, but it is a network
> API rather than a programming API. The Web uses that genericity
> in order to transfer state representations using a consistent set of
> semantics (the Web's messaging paradigm).
And I think (unlike my dist-obj friends) that the Web does that very well.
> That is also why the Web is not a distributed object system, and
> why a well-designed distributed object system doesn't have the same
> performance characteristics as a well-designed Web application.
I see your point.
> [It is possible to implement a distributed object system using HTTP,
> but that would be a poor design: it would suffer from both poor
> Internet-scale performance characteristics and a less optimal transfer
> syntax for fine granularity messages.]
Agreed -- a class project I managed last year with distributed objects
communicating using HTTP (worse -- communicating over Java RMI using
HTTP, bleah) had unsettlingly poor performance just in our local network.
> >Not necessarily more efficient mind you, but more powerful to
> >programmers adapting application events to new contexts: sending the
> >"unitsOnHandChanged" event to a local HTML ticker, to a spreadsheet in
> >another process on the same machine, or to a database store across the
> >Internet. My hunch is that by unifying the notification models for
> >different event sizes and performance requirements, we can simplify the
> >programming model by abstracting that there are just components and a
> >bus, and the components themselves can be local or distributed. Then,
> >as many middleware researchers do, we can focus on intelligently
> >supporting the kinds of performance constraints and distribution
> >topologies necessary below this service level.
> Ergo, CORBA. The problem with that theory is that messaging is
> one component of an overall system.
Right.
> A system will fail if the wrong messaging paradigm is used, just as a
> system relying on "unitsOnHandChanged" events being a representation
> of time will fail across the Internet. The messaging paradigm
> determines things like granularity, round-trips per action, fault
> tolerance, client-side vs server-side state, caching vs replication, etc.
Got it.
> I have yet to see an API-based middleware that allowed the programmer to
> select the appropriate messaging paradigm according to the system needs.
> If you can do that, color me interested.
Well, that's the dream... but right now I have no good answers as to how...
> >To be sure, this vision isn't a pachinko machine for distributing opaque
> >balls-o-bits from event sources to sinks: it relies on a more principled
> >format for describing data. If events were unified in an XML wrapper,
> >then perhaps filtering, aggregation, and type conversion make sense as
> >tree automata transformations. The way a "mouseDown" event percolates
> >up the stack to become a "sellStock" transaction event in the database
> >is akin to ascending a Jacob's Ladder of transformations, step by step.
>
> I'd worry about how well such a system would scale.
A concern I have up-front as well.
> >But I foresee a (potential) future where scripts, style sheets, parts of
> >documents, and processors are completely separated across the public
> >Internet. In this latency-is-no-longer-a-problem future, the
> >browser-centered event model will need to be ported to incorporate
> >decentralized notification protocols.
>
> You lost me here. How is this a "latency-is-no-longer-a-problem future"?
Poor word choice on my part. I foresee a future where latency is not
longer a problem not because latency issues go away but rather because
we know how to deal with latency differences, with the aggregation of
requests/notifications, with filtering, and so on.
> It sounds more like a latency-is-THE-problem future. Systems without an
> understanding of latency tend to do things like multiple round-trips for
> simple actions and strong typing of interfaces: things that cause the
> system to keel over and die when faced with an uncontrolled or high-latency
> network. A browser designed without an understanding of user-perceived
> performance is an unusable browser.
Or any other client for that matter. But it's a really good point.
> I think it would be possible to create a generic event interface,
> such that events can be registered, filtered, and received through
> a single API. I'd do it with a typed link abstraction using URIs for
> the type, filter, and notification method/recipient, and then a media
> type for the notification message syntax (I'm still an XML heretic).
> That would allow the messaging paradigm to be selected by the registrant
> according to the expected latency of each action and the context in which
> it is made.
Now you have me drooling. I'm about to short out my crummy Sparc 1 from
the overflow of saliva from my droolbucket, this is such a cool idea to me.
Thanks for giving me something to mull over for the next few days...
Now, in response to Lisa who in
http://xent.ics.uci.edu/FoRK-archive/apr98/0448.html
demonstrated that SHE'S thought about this a lot more than I have...
> Sounds like an API that could be built on RVP. With the addition
> that RVP does use XML for the more complex stuff, such as ACLs and
> detailed kinds of notifications on an object. MIME is used to specify
> notification message format. I'm co-author on this RVP stuff:
>
> http://www.ietf.org/internet-drafts/draft-calsyn-rvp-01.txt
>
> Not that I'm necessarily saying that RVP is a generic notifications
> tool. While we did try to keep it generic, we also had a very specific
> application in mind: people subscribing to people status.
Right, and now you know why I've been asking you about RVP.
If I really wanted to push it, I think the API could be built atop SIP,
which also tried to stay generic, but also was designed with a specific
application for rendezvous in mind: invite people to, establish, and
control multimedia sessions or calls. (Eve's here right now and she
said "event notifications are like ACL's++" which I thought was cool :)
http://www.cs.columbia.edu/~hgs/sip/
Alternatively, the single generic event API could be built atop HTTP,
which (I think, correct me if I'm wrong Josh) is the goal of GENA
(Generic Event Notification Architecture)...
http://www.ietf.org/internet-drafts/draft-cohen-gena-p-base-00.txt
Any of these alternatives seem better than just writing up a new one
from scratch, I must say. But as of right now, I have no answers: y'all
know as much as I do. Probably more. Speaking of which...
As for Mark's post
http://xent.ics.uci.edu/FoRK-archive/apr98/0440.html
> No shit Sherlock. 8-)
>
> http://www.interlog.com/~resnick/baker-res.html
>
> It's very component-centric (vs. document-centric), but the message is
> identical. No surprise there.
Your URL gives me a 404 error. I think Ron took the paper off of there.
But from what I recall reading your paper a few months ago -- correct me
if I'm wrong -- you weren't calling for, as Roy says, generic API-based
middleware that allows the user to tweak the messaging paradigm based on
his own system conditions and personal preferences.
> Beware transparency. But you knew that.
Indeed I do. In fact, I'm not calling for transparency at all: I want
explicit user control over things like event/message grain and
performance metrics.
> So how would an "actuate=auto" link work if only part of the linked
> document is retrieved? What's a script in the document containing that
> link to do, when the full document isn't retrieved? How will it know
> it's not the full document? Waldo still counts in the world of documents.
True. The issues you bring up would all need to be worked out in the
context of how DOM deals with scripts and XML files.
> SAX rules.
Absolutely. Good luck with the SAX-compliant iCal...
Finally, in one more bout of brain-flex that has me looking like I am an
idiot telling tales full of sound and fury signifying whatever, Elwood
wrote in
http://xent.ics.uci.edu/FoRK-archive/apr98/0447.html
something brilliant which has nothing to do with events, or maybe it
does in one of those interconnectedness kind of ways:
> Newton was born in 1642. It's generally recognised that he showed no
> promise in his early years at Cambridge and took a degree without
> distinction in 1665 - when he was 23.
I stand corrected. I guess van Doren comes from the "Rohit Khare School
of Embellishment and Propaganda" (TM).
On the other hand, Newton did manage to take a degree without
distinction several years earlier in his life than I'm going to (and
this is still up in the air) take my degree without distinction.
I found the rest of your writeup fascinating, Elwood -- thanks for
setting the record straight on that Fig of a Newton...
> Leibnitz in particular is an amazing polymath, who, foreshadowing
> today, published only what he could get funding and interest for and
> left the original work - in optics, mechanics, law, politics,
> probability theory - to be published after his death.
>
> These days, we skip wasting time on the 'original work' bit.
Is there such thing as original work these days, or does everything owe
to the fact that we're all in perpetual communication with peers,
friends, allies, foes, family, and those knaves in the bars and coffee
houses who won't stop tubthumping?
----
adam@cs.caltech.edu
Your manuscript is both good and original; but the part that is good is
not original, and the part that is original is not good.
-- Samuel Johnson