On Fri, Apr 25, 2008 at 10:30 AM, Atsushi Eno <[EMAIL PROTECTED]> wrote:
> Oops, sorrry, I was dead for couple of days and after that it has dropped > from my mind for a while. No problem, thanks for responding. > Here's my quick survey: > > - You cannot add any public extra stuff (such as Mono.Messaging.* classes) > in System.Messaging.dll. You have to create another assembly (such as > Mono.Messaging.dll) and use it together with System.Messaging.dll. That's interesting, I looked at System.Data initially, which included Mainsoft namespace classes, so I thought adding a different namespace into the same namespace would be okay. I am happy to change that. > It is sort of mess, as either > > - System.Messaging.dll depends on your extra assembly and hence yours > cannot use any types in System.Messaging.dll (e.g. you cannot define > IQueue.Deliver), or This is probably the easiest, but is adding a compile time dependency for System.Messaging.dll on another assembly acceptable? I assume we shouldn't be adding additional public classes to the System.* namespaces. - your extra assembly depends on System.Messaging.dll and hence any > types in yours inside System.Messaging.dll must be used through some > reflection foo, or > - you have to run cyclic build between those two assemblies (we do it > for System.dll, System.Configuration.dll and System.Xml.dll, which is > a mess). > > - At least MessageQueue.Create() should be implemented (otherwise it is not > practically functional as System.Messaging.dll). It would have to be done > by some configuration support to indicate one IMessagingProvider, and it > must not be dependent on System.Configuration.dll which is 2.0-only. > > - It would provide only simple part of Sys.Messaging functionality (it > would > apply to any JMS/AMQP based solution). We could still go with your > bridge implementation for a while as a compromised solution though. That's true, however the AMQP spec is not yet finished. I believe that there will be browsing and selector support in some of the later revisions. This will mean that the majority of the System.Messaging functionality is covered (including MessageQueue.Peek and MessageQueue.ReceiveById). The parts that probably won't be covered would be some of the specifics around the additional system queues (e.g. journal queues). Although AMQP does support sophisticated routing rules so it may be possible to emulate some of those features. I was hoping by adding a provider layer, other implementations could be added later, e.g. OpenWire for ActiveMQ or something Mono specific. > > > And as Miguel pointed out, we would have to avoid your GPLv3-based > component > as run-time dependency. I didn't see Miguel's message, but that is my mistake, it shouldn't of been v3. Is LGPL okay or would MIT be easiest for Mono? I have some comments on the patch details, but I'd put my general survey > first :) > > Atsushi Eno Unfortunately my timing here is not the best. I am about to head off travelling for about 4 months, so I won't be able to make any major changes until September. I'll fix the license and add MessageQueue.Create support before I go. I still want to help build a System.Messaging implemenation so I would be happy to receive any feedback you have in order to build something that will be useful for Mono. System.Messaging hasn't been touched a few years, so a few more months shouldn't hurt :-). Regards, Michael Barker. > > > Michael Barker wrote: > >> Hi, >> >> As I mentioned a couple of days ago I have a 0.0.1 version of a bridge >> between Mono and QPid. I have placed the code and a patch that adds an SPI >> to Mono on google code. http://code.google.com/p/mono-qpid/ >> >> There is quite a bit missing from the implementation, but basic sending >> and receiving with XML and Binary formatting works. >> >> Regards, >> Michael Barker. >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list@lists.ximian.com >> http://lists.ximian.com/mailman/listinfo/mono-devel-list >> >> >> > >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
