Er, well, you'd either have a very big API or a very generic API.
I'm a big believer in generic APIs for Internet-scale messaging.
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).
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.
[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.]
>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. 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.
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.
>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.
>...
>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.
>
>I would like my thesis to be about the unification of event models, from
>low-latency components talking among themselves locally on a client,
>through potentially high-latency components communicating with each
>other across the Internet. Beyond that, I suppose, anything is game
>still.
You lost me here. How is this a "latency-is-no-longer-a-problem future"?
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.
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.
....Roy