For SQL type permissions, we need a SQL object to hang onto.
(so let's make one up...)

CREATE MESSAGE QUEUE stock_updates RETAIN 3 HOURS;
GRANT INSERT ON stock_updates TO TRIGGER stock_watch;
GRANT SELECT ON stock_updates TO PUBLIC;
INSERT INTO QUEUE stock_updates VALUES ('stock=INPR,news=cancels merger');
/* Automatically notifies waiters on the message queue */

One of the design templates I presented at BorCon'99 was a message
passing "package" -- using tables and events. This is another way
that applications can get the functionality (simulating a message
passing system with special tables, etc).

Incidently, I suspect it will be useful to have multiple message
queues. While the filter approach can be used to have multiple
virtual message queues, it becomes more difficult to restrict
access.

Dave

-----Original Message-----
From: Jim Starkey [mailto:jas@...]
Sent: Wednesday, May 17, 2000 8:50 AM
To: IB-Architect@egroups.com; IB-Architect@egroups.com
Cc: Bill Karwin
Subject: Re: [IB-Architect] Messaging API


At 10:34 AM 5/17/00 -0400, Jim Starkey wrote:

>Following the theme proposed by Mr. Bill Karwin...

A problem with the proposal is security -- anybody connected
to the database can get any messages. Does anybody have
any idea of how this might be extended for SQL-like
security?

Jim Starkey

------------------------------------------------------------------------
Free Music: Take it with you! Diamond Rio MP3 Players
2 hours of play-time as low as $205.95 at eGroups' Group Buying
http://click.egroups.com/1/4186/4/_/830676/_/958578727/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com