At 06:11 PM 5/18/00 +1000, Jan Mikkelsen wrote:

>While talking about APIs are client implementations issues might be
>interesting to some, I think getting the semantics of the service right
>might be useful.
>
>Let's look at the requirements a bit.
>
>
>- A reliable broadcast message service. Client applications get an
> unbroken and ordered sequence of messages from a given point.

I think we can narrow the scope by asserting the following:

0. The purpose of messaging is to allow a connected program
to track database state.
1. All messages originate from the server.
2. Messages are only delivered to clients with a connection
to the server, and only messages posted during the
connection are candidate for delivery.
3. In all support environments, a second virtual circuit
for message/event delivery can be established without
undo cost.
4. There is no requirement for recovery of a message stream
is the database connection is broken for any reasons.

Do we agree so far? If so, I think we can duck the issues of
broadcast technologies and reliable delivery.

>
>Higher Level Naming
>
>At the application level, I would expect a database object for the
>message stream to be created. An application would subscribe to a
>message stream and be given the listening details by the server.
>

Declaring a server "channel" is a possibility, and would be a place
to apply security constraints. A message, then, would be posted
to a specific channel. A client, similarly, would request connect
to a channel. The advantages of named channels are twofold: 1)
They naturally subset messages, and 2) They provide a security hook.
I don't think the concept would add much to an implementation or
runtime cost. Is the conceptual complexity worth the gain?

>If filtering on a stream is to be performed, it should be done at the
>client, otherwise detecting gaps becomes problematic.
>

Here I disagree. In general, each client will have a specific interest
in a very limited corner of a database. Sending all messages to all
clients is both expensive and unnecessary. In the existing event
mechanism, posted events with no listeners are almost free, encouraging
fine granuality, highly specific (and therefore efficient) event. A
mechanism in which all messages were sent to all users would require
the application designer to be very miserly in this message architecture,
obviating some the benefits of the mechanism.

Like the event mechanism, a message for which there are no listeners
should be very, very cheap.

[None of this should be construed to indicate that I think messaging
is a good idea. Yet.]

>Message Structure
>
>I have deliberately left the message structure undefined. I think the
>message structure should either be defined in terms of native Interbase
>types, or left as a blob. The actual representation should be machine
>readable and small. Please, no mandated ASCII, and especially no XML!
>

No structure, no server side filtering, and the mechanism is too
expensive to use. May I remind you that ASCII means American
Stanard Code for Information Interchange? We're in the information
interchange business, so we should use the applicable standards.

>
>Security
>
>Submitting messages to the queue would require a database connection with
>appropriate permissions. If you really care about who listens or about
>message authentication, encrypt and/or sign the messages.

Surely you agree that access control is apppropriate for database
tables. Message streams, though transient, carry information. If
the granularity of access control where the database, then there
would be no reason to control access to messages. But since we
support a model where a client is allowed to see salary data,
for example, does it make sense to allow him to see messages
containing changes to salaries? I don't think so. If a message
facility is going to be useful, it has to support the same level
of security as the tables from which the message content is derived.

Jim Starkey