[Mono-list] Re: monoQLE

[A Rafael D Teixeira]

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