> 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
