Re: [boost] ASIO does not fully support Windows Runtime and a suggestion for providing support
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? I have recently been in contact with Steven Gates, who has been very helpful on my quest of porting Boost for WinRT. In conclusion, Niall, I thank you for educating me on the etiquette on Open Source public mailing lists. I trust you've also learned not to pull the trigger too quickly. Moshe
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.
On Friday, January 16, 2015 12:05 PM, Moshe Rubin wrote:
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?
Have you run the regression tests? If you haven't broken anything, then a pull request seems appropriate. I'm not sure if that pull request should go to the boost repo or Chris'. Ben
On 01/15/2015 08:05 PM, Moshe Rubin wrote:
In conclusion, Niall, I thank you for educating me on the etiquette on Open Source public mailing lists. I trust you've also learned not to pull the trigger too quickly.
Moshe
Moshe - I'm sorry your reception to the list was cold. Niall does not moderate the list and in fact you followed the correct procedures for Boost. Decisions about Boost as well as features/improvements to libraries are discussed on this mail list http://www.boost.org/community/requests.html. That is the policy. There is not some separate side channel or handshake that is required first. Unfortunately, Chris doesn't participate on the dev mail list but he is very responsive, as you have found out, if you contact him through other means. I look forward to your involvement in Boost! Take care - michael -- Michael Caisse ciere consulting ciere.com
On January 16, 2015 2:34:08 AM EST, Michael Caisse
On 01/15/2015 08:05 PM, Moshe Rubin wrote:
In conclusion, Niall, I thank you for educating me on the etiquette
on Open Source public mailing lists. I trust you've also learned not to pull the trigger too quickly.
I'm sorry your reception to the list was cold. Niall does not moderate the list and in fact you followed the correct procedures for Boost. Decisions about Boost as well as features/improvements to libraries are discussed on this mail list http://www.boost.org/community/requests.html. That is the policy.
Right. To be clear, this list *is* an appropriate channel for raising issues, suggesting fixes, etc., for Boost libraries. Boost.Asio, like Boost.Spirit, is unusual in that it has a separate mailing list and support mechanism. That doesn't mean posts here are out of place, just that you'll often be redirected elsewhere for those libraries.
There is not some separate side channel or handshake that is required first. Unfortunately, Chris doesn't participate on the dev mail list but he is very responsive, as you have found out, if you contact him through other means.
Thanks to Edward and Michael for jumping in.
I look forward to your involvement in Boost!
+1 ___ Rob (Sent from my portable computation engine)
On 16 Jan 2015 at 4:05, Moshe Rubin wrote:
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.
Ok, I clearly read meaning into your original post which wasn't there. I apologise. I have a partial solution for the other problem Chris mentioned now that WinRT 8.1 has the Winsock API, that of missing Windows API functions. It isn't widely known that mingw-w64 provides a winstorecompat library which provides emulations of win32 APIs using WinRT APIs, and therefore by linking to it with one fell swoop can make many of the forbidden symbols go away. The winstorecompat library was developed by VLC as part of their KickStarter funding to port VLC to WinRT, so by now it is surely reasonably well tested. You'll find the library at http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libr aries/winstorecompat/src/, and just from the filenames of the source files you'll see quickly what is supported. It may therefore be worth compiling ASIO standalone in C++ 11 mode targeting mingw-w64 with the winstorecompat build switched on, and see how many of the unit tests pass plus how many banned APIs are still generated in the executables. It would at least give you a good idea of how much work remains for a complete WinRT port, and who knows, it may just all work and you're done (on mingw-w64 at least). If you need help with configuring the mingw-w64 toolchain for a WinRT target, try examining the VLC sources as I'd assume this is not a well documented use case. I hope this is useful. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (6)
-
Ben Pope -
Edward Diener -
Michael Caisse -
Moshe Rubin -
Niall Douglas -
Rob Stewart