From: Hugues Lismonde <[EMAIL PROTECTED]>
Having discussed this question within the (small) company I work for, here is a resume of our though about MSMQ and Indigo.
On Windows platforms, duplicating System.Messaging/MSMQ to snap in MSMQ 2.0/3.0 Services should be possible, but on others platforms, according to Microsoft Communications Protocol Program ( http://members.microsoft.com/consent/Info/Default.aspx ) and perhaps patents, I presume that some legal aspects will have to be explored before implementing the Message Queuing Protocols suite (including SOAP Reliable Messaging Protocol aka SRMP).
Just to clarify a bit: MonoQLE is a project to build a backend for the classes in the System.Messaging namespace, not a snap in replacement for MSMQ. It is not intended to interoperate at any level with MSMQ. The idea is for anyone interested deploy MonoQLE either in Windows or Linux, and run your queues thru it.
Security issues may complicate the picture but probably we will opt to use the LDAP based mono implementation of DirectoryServices, so that no one would have to duplicate/migrate the whole ActiveDirectory forests to administer MonoQLE permissions.
As the sole purpose is to write interoperable software under Sect. 1201 (f) Reverse Engineering exception of the DMCA, the gate is perhaps not closed, but it should be asked to a legal expert.
I think that DMCA doesn't enter the picture in the MonoQLE project. DMCA is something the US legislators will hopefully amend before it's too late... But in pratical terms interoperation with MSMQ is not a goal.
According to Mono Roadmap (http://www.go-mono.com/mono-roadmap.html), WSE will be the way to go. The future release of WSE before Indigo (perhaps 3.0) should support WS-ReliableMessaging ( http://www.dynamic-cast.com/mt-archives/000024.html ). There again rights and licenses about WS-ReliableMessaging should be checked twice before.
Unfortunate, but I think that is why MS/IBM created WSI, first of all, instead of continuing WebServices standardization inside W3C: to be able to embed royalty-earning patents inside of the WS "standards".
Similar to the great approach of Mono.Data.ProviderFactory, such modularity could also be adopted to support different Reliable Messaging semantics ( http://xml.coverpages.org/reliableMessaging.html ). We can already think about supporting http://www.freebxml.org/ and/or http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm
That was the plan for System.Messaging from the start, so that MonoQLE client/daemon pair would be just the default backend, but that you could plug any other compatible client (like the behaviour you have in Java's JMS).
Hoping that the clarifications were good enoughj..
Best regards,
Rafael Teixeira Brazilian Polymath Mono Hacker since 16 Jul 2001 MonoBrasil Founding Member - Membro Fundador do MonoBrasil English Blog: http://monoblog.blogspot.com/ Brazilian Portuguese Blog: http://monoblog.weblogger.terra.com.br/
_________________________________________________________________
MSN Messenger: instale gr�tis e converse com seus amigos. http://messenger.msn.com.br
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
