Re: RFC 350 (v1) Advanced I/O (AIO)

> you would do:
> 
>         $sock = AIO::Open( Host => 'www.perl.org',
>                            Port => 80 ) ;

> Similarly for LWP you would just do:
> 
>         $sock = AIO::Open( Url => 'http://www.perl.org' ) ;

>         $event = AIO::Open( Host => 'www.perl.org',
>                             Port => 80
>                             Callback => $obj  ) ;
> 
>         $event = AIO::Open( Url => 'http://www.perl.org/index.html',
>                             Callback => $obj  ) ;

I like this overall. Very nice.

One of the goals in RFC 14, and the reason why I chose to go the
"handler" route, is to make it look like open() had just been beefed up:

   $file = open "/etc/motd";
   $dir  = open dir "/usr/local";
   $http = open "http://www.yahoo.com";

However, the under-the-hood implementation of dir->open and http->open
is not explored; I was trying to create a consistent user-level
interface that does not require the complex syntax shown above. And from
this angle, I think RFC 14 has a lot to offer.

But, one thing that I think is worth exploring is how we could merge
this ideas, since I think the AIO system could well be a very viable
implementation. One thing I could see is ditching the handler idea and
instead just having people use URL's:

   $file = open "/etc/motd";
   $dir  = open "dir:/usr/local";
   $dir  = opendir "/usr/local";   # legacy shortcut
   $http = open "http://www.yahoo.com";

The CORE::open would be smart enough to then dispatch to the underlying
AIO->open (or whatever) and do something akin what you've listed above.

I like the AIO idea; if we could stick it under the hood (but still
accessible, like IO::, if you really want to use it directly), I could
see it implementing Perl 6 IO.

One last thing: I could see a class hierarchy as being potentially most
effective for something like this; perhaps you could have AIO::HTTP,
AIO::File, AIO::Dir, and so on, with the main AIO class serving as the
base/dispatch class.

-Nate