On 1/15/2015 11:05 PM, Moshe Rubin wrote:
I highly object to the tone of your response. Bringing up a matter on
this mailing list related to a Boost library is not a command for anyone
to do anything. By responding the way you have done you are discouraging
people with issues from using Boost mailing lists to start a discussion
about a particular library.
I apologise if I have offended anyone on the list, including you
Edward.
My thanks to Edward for standing up for a relatively new poster to this mailing list. There was absolutely no malicious or similar intention in my post, and certainly no "commanding and impatient tone". My intention was to improve ASIO, which is an incredible technological achievement. Our needs for a ported Boost for WinRT, as the needs of many others, are immediate, so I used the methods known to me, including posting to this mailing list. If I had a nickel for every WinRT developer pining for a complete port of Boost for WinRT, I'd probably be a rich man <g>.
However, there is an etiquette when dealing with deficiencies in open
source libraries. You first raise the issue with the library's
maintainers before going onto public lists - and before I replied to
the OP, I checked the github ASIO issue tracker and the Boost issue
tracker and found no mention of the deficiencies. It may be the case
that the OP has spoken to Chris by private email, but his post did
not indicate that.
I am willing to learn the ropes and thank you for pointing out the correct procedure. As a matter of fact, I used a two-pronged tactic just in case and sent the same email to Chris in parallel (see his response below).
Furthermore, Chris fairly bluntly stated in the
ASIO release notes which added WinRT support that that support would
be limited, and he went into some detail as to how and why. That
would strongly suggests that the maintainer is well aware of the
limitations, and has a strong idea of what should be done about them
(if anything). Moreover, if he has left out a particular support for
something, he may well have very good reasons for that, including the
cost benefit reason.
Indeed, I had not checked the ASIO release notes, and now know that that is most important. Reading them now, I see that Chris limited his port. As a WinRT developer, I know why he decided to do so.
So, go raise it with the maintainer first, and that's probably best
done as I mentioned via the ASIO github issue tracker which Chris
definitely responds quickly to. If the maintainer refuses to support
what you need, *then* come onto this list to see if anyone else is
having the same problem, *then* see if you can put together a
coalition of the willing. However, to be honest, I think the
maintainer will be happy to improve WinRT support, you just need to
prearrange what form he'd prefer it to come in.
Here is Chris's courteous reply to me:
<quote>
Thanks for your email. I was not aware that Windows Phone now supports Winsock. This is great news.
However, I am a bit confused by your proposed design. I don't believe we need a new socket service at all. If Windows Phone now supports Winsock then we simply need to prevent BOOST_ASIO_WINDOWS_RUNTIME from being defined - see asio/detail/config.hpp. Then, provided that BOOST_ASIO_WINDOWS *is* defined and BOOST_ASIO_HAS_IOCP is *not*, it will use the existing select()-based reactive_socket_service backend. This backend is already supported on Windows, and was used in the past to support Windows 9x and WinCE.
I suggest you start by modifying asio/detail/config.hpp to make those changes, and then see what errors happen after that. There will most likely be other changes needed to work around Windows API functions that are still unsupported on Windows Phone.
Cheers,
Chris
</quote>
And BTW, after you've talked to Chris and gotten green lit by him,
absolutely do ping this list with what you've agreed to do and ask
for feedback on it. The people I'm currently contracting for would be
very interested in improved WinRT support in ASIO. I'm sure so would
others on the asio-users ML. And as ASIO is going to be the
Networking TS, I daresay so would Microsoft, indeed you might even
get some improvements to WinRT to help ASIO along - we have the main
Microsoft engineer who ported Boost to WinRT on this mailing list.
So here I have a question: when I've followed up on Chris's suggestions and have ASIO working for ASIO, what should I do next? Return to the mailing list to announce the fact and ask for feed as you suggest, or schedule a GitHub pull request?
The usual action is a Github pull request. Then it is up to the ASIO maintainer(s) to handle the pull request. The pull request also allows for further comments concerning the requested change but that is all handled by the Github pull request mechanism.