[rabbitmq-discuss] Porting .NET client to WinRT API (Windows 8).

[Nathan Brown]

Hi Emile (and others),

I have the Windows 8 Modern UI (Windows Store) implementation basically
working.  I'm trying to polish up a sample project.

The thing with the Windows.Networking.Sockets is that it breaks
compatibility with every version of Windows before Windows 8 and Server
2012.  So support will have to swap in code as needed and compile separate
DLLs.  The SSL implementation is so different, that I'm not even sure if
there is the equivalent of having the application handle or know about its
certificates.  I'm also not familiar with setting up and testing SSL in
RabbitMQ.

The Generic changes should all work on Mono, so all of that can be shared.
 I do wonder if we want to move completely away from IDictionary to
IDictionary<string, object>.  Specifically look at the
WireFormatting.WriteTable() and MethodArgumentWriter.WriteTable() methods.
 With my current method of having both overloads, callers need to cast to
the specific interface they are using because the concrete Dictionary<,>
implements both.

Currently, I have the Windows Store project working with sharing most files
and having copies of some files. Since not many lines change compared to
the size of the files, it might be beneficial to use #if NETFX_CORE in the
main files and share everything.  What do you think?  The files that were
copied and not currently shared are:

"..\RabbitMQ.Client\src\util\**\XmlUtil.cs;..\RabbitMQ.Client\src\client\**\ConnectionFactory.cs;..\RabbitMQ.Client\src\client\**\ConnectionBase.cs;..\RabbitMQ.Client\src\client\**\Frame.cs;..\RabbitMQ.Client\src\client\**\SessionManager.cs;..\RabbitMQ.Client\src\client\**\SocketFrame*.cs;..\RabbitMQ.Client\src\client\**\SslHelper.cs;..\RabbitMQ.Client\src\client\**\SslOption.cs;..\RabbitMQ.Client\src\client\**\Protocols.cs"

Another area that was different was getting environment variables.  Windows
Store Apps don't have access to ConfigurationSettings,
ConfigurationManager, or Environment.GetEnvironmentVariable but instead
uses Windows.Storage.ApplicationData.  I'm not sure if it's a good idea to
have the library try to access those values (primarily the AMQP_PROTOCOL)
or just make it clear they have to be pragmatically set.  I don't think
there's an example of the protocol being pragmatically set though.

Having the library use Windows.Storage.ApplicationData keeps it from
running on the desktop because there is no Application Identity.  It also
keeps some of the tests from being runnable on NUnit.  Any thoughts on this?

Thanks,

Nathan Brown


On Fri, May 10, 2013 at 2:45 AM, Emile Joubert <emile at rabbitmq.com> wrote:

>
> Hi Nathan,
>
> On 07/05/13 17:34, Nathan Brown wrote:
> > Can you guys review these changes and consider incorporating them into
> > the mainline codebase?
>
> Yes, and thanks! We'd like to make use of your contribution, but it will
> take a while to review. May I request that you sign a contributor
> agreement in the meantime? I'll contact you off-list.
>
> > The networking area is another area of change in WinRT.  It will have to
> > involve a separate project because System.Net.Sockets has been removed
> > and Windows.Networking.Sockets has been added.  I am still working on
> > porting the networking code to the WinRT API, but that will hit far
> > fewer files than the non-generic to generic collection conversion.
>
> Yes, Socket and SSL-related functionality is more localised.
>
> We would be reluctant to relinquish the compatibility of the current
> .net client with mono. I'm not sure whether that is necessarily the
> implication, but it might be something to consider.
>
>
>
>
> -Emile
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20130511/9f8581d0/attachment.htm>