I took the liberty to post my answers to the Mono comunity, too.

Peter Van Isacker, wrote:

1. I was wondering what your initial thoughs are on the monoQLE project.

Mental note: ... I may have to update the summary at http://sourceforge.net/projects/monoqle/


Foremost it need to be a backend for mono's System.Messaging. So that someone can write queue-based aplications in mono. The lacking part here is interoperability.

JMS interoperability, is a secondary goal, meaning that java programmers could write/read messages to/from MonoQLE queues. Even, interoperating with mono code, through them.

Third, I'm following some efforts on creating standards for the wire protocol of queue servers, but it seems they aren't supported by the bigger players, so see below, for my current thoughts on that.

Fourth, I intend to make it easy for any bridge developers, to port their MSMQ-related products to MonoQLE. That would allow "transparent" interoperation with IBM Websphere MQ, for example.

What I don't intend to do is to study and emulate MSMQ wire protocols, to interoperate directly with it. Maybe Samba developers may be interested on doing it, because of how tangled it is with NT/AD security.

2. What does QLE stand for?

MonoQLE = Mono Queue server Linux Edition, although it should work on any platform where mono is supported, the initial focus is Linux because of dependencies it may have on deployment and daemon configuration/control.


I twisted the acronym, a bit, to make it sound like monocle (that antique single-eye glass).

3. It appears you lack coders, I think I have some free time. :)
   Although I don't know where exactly to start,
   except for stubbing System.Messaging

That would be a great start. I did some mininal stubbing of other namespaces in mono to make the MonoQLE daemon/service, compile. But I didn't have the time to stub System.Messaging itself, beyond my months-aged initial efforts.


Please, go ahead!!!

Some more details:

I'm still defining how to plug a provider-based mechanism on System.Messaging, and then implement a MonoQLE-specific provider, as the default.

For the wire protocol, between the provider and the daemon, I'm inclined to use remoting, with it's configurability being an interesting plus, that also brings interoperation via Web Services, to the picture.

Thanks, and Happy Hackings,


Rafael Teixeira Brazilian Polymath Mono, MonoQLE Hacker


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail


_______________________________________________
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list

Reply via email to