Hello. I believe Chris Winters had a desire/ itch to do some work on message queue
systems. He's on this list, so hopefully he'll reply soon also. I've had a bit of experience using a system with some similarities with IBM's MQ product, and overall I was quite impressed. It had nice features like transactions, asynchronous and synchronous messaging, queing etc. I believe is what you are suggesting design an interface similar in concept to DBI. The difficulty comes when tyou are trying to emulate features on platforms that don't naturally lend them selves to them. Trying to support things like SMS and a business product like MQ with the same interface could be a great deal of work. Trying to do so without limiting the strengths of the differing message products could be very interesting. Another aspect is the formatting of the message - it's nice to have a logical seperation between the data being sent and the format that the message gets written in, so that the client is responsible for converting a data structure into XML, or using Freeze::Thaw e.t.c Then you have the problem of asccii and binary messages,and converting these between incompatable systems. It looks like a lot of work. Good Luck. Cheers, Steve. Aaron Johnson wrote: > I want to do some work regarding messaging* for P5EE and would like > comments on the following: > > What type of messaging systems are in use in your organization? > > What is the most important messaging system in your organization? > > Is someone else is already thinking of doing or done work in this area > that would like to collaborate? > > What is your organizations method of notification when there is a system > problem? > > Is there a category like this already on P5EE and I missed it or am I > possibly clumping too much into one title? > > These efforts would be different from Spread. Spread appears (in my > glance) to be a daemon. What I am proposing are the interfaces and > possibly allowing for them to work in conjunction with one another, > existing messaging solutions like Jabber, Sendmail etc. That is the > ability to message someone or something with a variety of methods as > defined by business rules. Spread still has a place, but I consider it > more a notification system then a robust messaging solution. A Perl > module to interact with it may even be a side benefit of this project. > > I fully realize I have only scratched the surface of this topic/debate. > > Aaron Johnson > > * My summary of messaging is getting information to and from various > objects, these objects can be people, devices, etc. This includes but > is by no means limited to SMS, IM, Email. > > _____________________________________________________________________ > This message has been checked for all known viruses by the > MessageLabs Virus Scanning Service.
