<div dir="ltr">Hi Emile (and others),<div><br></div><div>I have the Windows 8 Modern UI (Windows Store) implementation basically working. I'm trying to polish up a sample project.<br><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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:</div>
</div><div><br></div><div>"..\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"<br>
</div><div><br></div><div style>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.</div>
<div style><br></div><div style>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?</div>
<div style><br></div><div style>Thanks,</div><div style><br></div><div style>Nathan Brown</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 10, 2013 at 2:45 AM, Emile Joubert <span dir="ltr"><<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Hi Nathan,<br>
<div class="im"><br>
On 07/05/13 17:34, Nathan Brown wrote:<br>
> Can you guys review these changes and consider incorporating them into<br>
> the mainline codebase?<br>
<br>
</div>Yes, and thanks! We'd like to make use of your contribution, but it will<br>
take a while to review. May I request that you sign a contributor<br>
agreement in the meantime? I'll contact you off-list.<br>
<div class="im"><br>
> The networking area is another area of change in WinRT. It will have to<br>
> involve a separate project because System.Net.Sockets has been removed<br>
> and Windows.Networking.Sockets has been added. I am still working on<br>
> porting the networking code to the WinRT API, but that will hit far<br>
> fewer files than the non-generic to generic collection conversion.<br>
<br>
</div>Yes, Socket and SSL-related functionality is more localised.<br>
<br>
We would be reluctant to relinquish the compatibility of the current<br>
.net client with mono. I'm not sure whether that is necessarily the<br>
implication, but it might be something to consider.<br>
<span class=""><font color="#888888"><br>
<br>
<br>
<br>
-Emile<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>