On 4/26/06, Christopher Kohlhoff <chris@kohlhoff.com> wrote:

Hi James,

--- James McCartney <asynth@io.com> wrote:

...

This library's name should be changed as it will lead to confusion. There is already an audio i/o library called ASIO which has been in use for years in audio applications and supported by many software vendors and hardware manufacturers.

http://en.wikipedia.org/wiki/Audio_stream_input_output http://whatis.techtarget.com/definition/0,,sid9_gci213488,00.html

I don't think it will lead to confusion.

Both of the links you give describe ASIO as a "protocol" or "interface", not a C++ library. There are plenty of examples in computing where similar names are used in different domains, without difficulties.

Also, asio is not an acronym

In what way is it not?

"Olaf van der Spek" <olafvdspek@gmail.com> writes:

...

Also, asio is not an acronym

In what way is it not?

If it were an acronym, for what word would the "s" stand? "Asychronous S(omething) Input Output"? -- Chris

Hi Markus, --- Markus Schöpflin <markus.schoepflin@comsoft.de> wrote:

Chris Uzdavinis wrote:

...

"Olaf van der Spek" <olafvdspek@gmail.com> writes:

...

...

Also, asio is not an acronym In what way is it not?

If it were an acronym, for what word would the "s" stand?

"Asychronous S(omething) Input Output"?

It's a perfectly fine acronym. See http://en.wikipedia.org/wiki/Acronym.

What I mean is that Asio is not intended to stand for anything, i.e. it is not an abbreviation. Yes, the letters "io" in the name are meant to convey that it is related to I/O, and the overall name is supposed to suggest asynchronicity. However it was conceived as a name only, not a shortened form. Q: Does asio stand for: ASynchronous I/O Asynchronous and Synchronous I/O All Sorts of I/O A: No, it doesn't stand for anything; or A: Whatever works for you :) Cheers, Chris

Hi Olaf, --- Olaf van der Spek <olafvdspek@gmail.com> wrote:

But wouldn't a name that does stand for something be much better?

So... what does Olaf stand for? ;) Take xpressive for example, which I think is a great name. If you don't already know what the library does, you have to ask. But once you know, it makes perfect sense and it's easy to remember. Cheers, Chris

I have some ideas for library naming in the Boost context: For a small library, the name should be descriptive like Boost.ProgramOptions, so by looking at the name you already know what the library does. For a large library, in practice, it has two names, the acronym (also namespace) and the full name. The acronym is best when it's short. So the boost examples are: The Boost Graph Library - or BGL C++ Template Metaprogramming (Boost Template Metaprogramming Library) - or MPL In these cases the full name matches also the title of the published books. So for the current asio it probably makes sense to establish the short and long names now, given the broad appeal for the library. So for asio you could consider these names The Boost IO Library - BIL C++ IO Library - IOL The short name should not have any hyphens as it doesn't look nice in the namespace. It is also good to check in Google that the acronym is not widely used. If you check BGL or MPL, you get the right link in the first results On 4/27/06, James McCartney <asynth@io.com> wrote:

On Apr 27, 2006, at 5:34 AM, Christopher Kohlhoff wrote:

...

What I mean is that Asio is not intended to stand for anything, i.e. it is not an abbreviation.

Yes, the letters "io" in the name are meant to convey that it is related to I/O, and the overall name is supposed to suggest asynchronicity. However it was conceived as a name only, not a shortened form.

Q: Does asio stand for:

ASynchronous I/O Asynchronous and Synchronous I/O All Sorts of I/O

A: No, it doesn't stand for anything; or

A: Whatever works for you :)

So, the name functions sort of like a brand or trademark, then. Hmm..

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 4/26/06, Paul A Bristow <pbristow@hetp.u-net.com> wrote:

to escape from the async-ness which doesn't seem important in the bigger picture into which this library promises to fit in future?

boost::asio big contribution is in async handling ( networking now and file i/o in the future) so I think is hard to find a better, shorter and more precise name

"Olaf van der Spek" <olafvdspek@gmail.com> wrote in message news:b2cc26e40604260753h6dce7c95k85dd624cc29dadea@mail.gmail.com...

On 4/26/06, Jose <jmalv04@gmail.com> wrote:

...

On 4/26/06, Paul A Bristow <pbristow@hetp.u-net.com> wrote:

...

to escape from the async-ness which doesn't seem important in the bigger picture into which this library promises to fit in future?

boost::asio big contribution is in async handling ( networking now and file i/o in the future) so I think is hard to find a better, shorter and more precise name

Why should it be shorter? I think async_io is both better and more precise as it's immediately clear what the a stands for.

I agree. But if the plan is to also provide synchronous I/O, then the name should be broadened, IMO. --Beman

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Silex | Sent: 26 April 2006 16:38 | To: boost@lists.boost.org | Subject: Re: [boost] there already is an ASIO. | | libio ? | ionet ? | | :) | | On 4/26/06, Beman Dawes <bdawes@acm.org> wrote: | > But if the plan is to also provide synchronous I/O, | then the name should be broadened, IMO. fario ? iofar? (io to places not so local and yet not covered by filesystem - perhaps networked). Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html

Beman Dawes wrote:

I agree. But if the plan is to also provide synchronous I/O, then the name should be broadened, IMO.

Or left at Asio, which could stand for "Asynchronous and Synchronous I/O". Sebastian Redl

Beman Dawes ha escrito:

"Olaf van der Spek" <olafvdspek@gmail.com> wrote in message news:b2cc26e40604260753h6dce7c95k85dd624cc29dadea@mail.gmail.com...

...

On 4/26/06, Jose <jmalv04@gmail.com> wrote:

...

On 4/26/06, Paul A Bristow <pbristow@hetp.u-net.com> wrote:

...

to escape from the async-ness which doesn't seem important in the bigger picture into which this library promises to fit in future?

boost::asio big contribution is in async handling ( networking now and file i/o in the future) so I think is hard to find a better, shorter and more precise name

Why should it be shorter? I think async_io is both better and more precise as it's immediately clear what the a stands for.

I agree. But if the plan is to also provide synchronous I/O, then the name should be broadened, IMO.

UIO (Unified/Universal I/O)? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

On 4/28/06, Giovanni P. Deretta <gpderetta@gmail.com> wrote:

Joaquín Mª López Muñoz wrote:

...

UIO (Unified/Universal I/O)?

While I think that ASIO is perfectly fine, there is any reason to change it, I vote for UIO too.

At this rate, Boost.OldMacdonald -- EIEIO :P Thinking that asio isn't going to be much better or worse than any other *io*, ~ Scott McMurray

On Sat, 29 Apr 2006 18:53:07 +0200, Giovanni P. Deretta wrote

...

At this rate, Boost.OldMacdonald -- EIEIO :P

LOL :-)

Because of cultural barriers, it actually took me 24 hours to get the joke... now i did and had a good laugh :) In the end, we should just stick with ASIO, or if chris has some spare time in his hands, what about a naming contest? ... I know, I know, just kidding :)

I agree -- let's leave the name alone. And please no contests to figure out some sort of reasonable set of words for EIEIO ;-) Jeff

Jeff Garland wrote:

On Sat, 29 Apr 2006 18:53:07 +0200, Giovanni P. Deretta wrote

...

...

At this rate, Boost.OldMacdonald -- EIEIO :P

LOL :-)

...

Because of cultural barriers, it actually took me 24 hours to get the joke... now i did and had a good laugh :) In the end, we should just stick with ASIO, or if chris has some spare time in his hands, what about a naming contest? ... I know, I know, just kidding :)

I agree -- let's leave the name alone. And please no contests to figure out some sort of reasonable set of words for EIEIO ;-)

Enlightened Interface Enriched Input Output :P Cheers! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Paul A Bristow wrote:

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Giovanni | P. Deretta | Sent: 28 April 2006 18:41 | To: boost@lists.boost.org | Subject: Re: [boost] there already is an ASIO. | | Joaquín Mª López Muñoz wrote: | > | > UIO (Unified/Universal I/O)? | > | | While I think that ASIO is perfectly fine, there is any | reason to change | it, I vote for UIO too.

I like it - and much better than my previous feeble suggestions.

The choice should depend on whether the future use or development of asio is going to outgrow the 'as' part. I get the impression that it probably will do.

Paul

I vote for EIEIO. It's unpronounceable, doesn't mean anything AND comes from a children's song. Or how about SQUIOD? That sounds pretty good.

On Wed, Apr 26, 2006 at 03:33:51PM +0100, Paul A Bristow <pbristow@hetp.u-net.com> wrote:

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Chris Uzdavinis | Sent: 26 April 2006 15:10 | To: boost@lists.boost.org | Subject: Re: [boost] there already is an ASIO. | | "Olaf van der Spek" <olafvdspek@gmail.com> writes: | | >> Also, asio is not an acronym | > | > In what way is it not? | | If it were an acronym, for what word would the "s" stand? | | "Asychronous S(omething) Input Output"?

Or CIO for Chronous Input Output?

to escape from the async-ness which doesn't seem important in the bigger picture into which this library promises to fit in future?

But I still feel we can do better still...

Hm, you mean like "chronic input output"? Andreas Pokorny

On Apr 26, 2006, at 6:12 AM, Christopher Kohlhoff wrote:

Both of the links you give describe ASIO as a "protocol" or "interface", not a C++ library. There are plenty of examples in computing where similar names are used in different domains, without difficulties.

The ASIO SDK is a C++ library. You can download it from here: http://www.steinberg.de/329_0.html --- james mccartney

James McCartney <asynth@io.com> wrote:

...

The ASIO SDK is a C++ library. You can download it from here: http://www.steinberg.de/329_0.html

...after you click through the page where it says: "ASIO is a trademark and software of Steinberg Media Technologies GmbH" ^^^^^^^^^

that's a genuine problem, but it's arguable if "boost.asio" qualifies as trademark violation. B.

Christopher Kohlhoff wrote:

Hi James,

--- James McCartney <asynth@io.com> wrote:

...

This library's name should be changed as it will lead to confusion. There is already an audio i/o library called ASIO which has been in use for years in audio applications and supported by many software vendors and hardware manufacturers.

http://en.wikipedia.org/wiki/Audio_stream_input_output http://whatis.techtarget.com/definition/0,,sid9_gci213488,00.html

I don't think it will lead to confusion.

I have to admit, when I returned to boost after some time away and saw a lot of discussion about the Asio library, I did wonder why boost was getting involved in audio! Of course, once I got around to reading the content of the postings it cleared things up - but even if I suspected that Boost's Asio was not the same as Steinberg's, I didn't realise that it was to do with Asynch (or Synch) IO until I looked into it more closely. It's more for the latter reason that I too would welcome a (slight) change to the name (remotely possible trademark issues aside). From the current suggestions I like async_io, although I see that it could be a problem if a synchronouse version was implemented. I like the ambiguity of the S, which some have exploited to mean: Aynch/ Synch IO. Perhaps we could keep the letters, but stress the grouping like this: as_io ? Just my thoughts. I like the library and would to hate to think it got overlooked by some because the name doesn't give too many clues as to purpose. Best regards, [)o IhIL..

Olaf van der Spek wrote:

On 4/27/06, Phil Nash <phil.nash.lists@gmail.com> wrote:

...

I have to admit, when I returned to boost after some time away and saw a lot of discussion about the Asio library, I did wonder why boost was getting involved in audio! Of course, once I got around to reading the content of the postings it cleared things up - but even if I suspected that Boost's Asio was not the same as Steinberg's, I didn't realise that it was to do with Asynch (or Synch) IO until I looked into it more closely.

It's more for the latter reason that I too would welcome a (slight) change to the name (remotely possible trademark issues aside). From the current suggestions I like async_io, although I see that it could be a problem if a synchronouse version was implemented. I like the ambiguity of the S, which some have exploited to mean: Aynch/ Synch IO. Perhaps we could keep the letters, but stress the grouping like this: as_io ?

Would that avoid "I didn't realise that it was to do with Asynch (or Synch) IO until I looked into it more closely."?

Well, not as much as I'd like, but I think it does help. By isolating the "io" part, it makes it more obvious that those letter belong together. As for the "as", well on its own (but in the context of io) it does suggest either ASync or Async/ Sync. It's just when you run them together that the meanings are less clear (to me).

Although it does/may provide support for sync operations, the main purpose of the library are the async operations AFAIK.

Agreed. Best regards, [)o IhIL..

Hi Olaf, --- Olaf van der Spek <olafvdspek@gmail.com> wrote:

Although it does/may provide support for sync operations, the main purpose of the library are the async operations AFAIK.

I hope that's not the case. The library aims to make async as convenient to use as sync. Synchronous operations are comprehensively supported, and are not an afterthought. Cheers, Chris

Hi Olaf, --- Olaf van der Spek <olafvdspek@gmail.com> wrote:

True, but sync operations are already quite easy to do easily and 'portably' via BSD sockets.

Hmmm, for very simple use cases maybe. But consider... - Does the socket API need to be initialised (WSAStartup etc)? - What is the best way to handle SIGPIPE if you write to a disconnected socket? - Thread-safety (or otherwise) of host resolution functions like getaddrinfo. - Whether IPv6 capable functions are available (they're not on Windows 2000). - Functions for scatter-gather operations (recvmsg/sendmsg and WSASend/WSARecv) have quite different signatures. - Whether socket option values are passed as void* or char*. etc, etc. In my experience, if you want your code to be portable it will quickly acquire #ifdefs to cope with these differences. And that's assuming you discover the differences at all - what's the bet that there are people who port socket code to Mac OS X who aren't aware that getaddrinfo isn't thread safe. Cheers, Chris