-----Original Message-----
From: Jim Starkey [mailto:jas@...]
Sent: Thursday, May 18, 2000 10:22 AM
To: IB-Architect@egroups.com; IB-Architect@egroups.com
Subject: Re: [IB-Architect] Messaging API

Responding to Jan Mikkelsen wrote:

<Snip>

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

There are two choices to be made, Jim, extend Events or build Messaging
- You choose. Although at first glance events seem to be a useful
feature, I have yet to be able to use them, they do not provide a
meaningful context in the message. This requires a very time consuming
to determine the context, the "cost" of which far outweighs the value of
the message.

If messaging was available today, then creating a custom DB
synchronization program/routine (one which creates read-only copies of
the DB) would (to my mind) be a *lot* simpler.

<snip>

>
>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.

I thought you said you wanted a reasonably lightweight solution?

I have to most, most seriously disagree with you. Since message is a
tool for the programmer to use as necessary, it is the responsibility of
the programmer to use is wisely. Nothing in the proposed design
requires that meaningful data needs to be part of the message (as I said
in a previous posting). The tools provide for the programmer to be as
secure or unsecure as necessary, at their risk.


Sean