> This is nutso... shall we open->ssh and open->telnet and
> open->any_protocal_under_the_sun in the core?
Well, just because the hooks are there doesn't mean all the member
modules have to be in core. The idea would be, as Tom Hughes suggests:
> That is if the core provides a way for modules to register as
> handlers for certain types of filename - the when you load a
> module like LWP it would register things like http and ftp that
> it knows how to handle and open's for those types would be handed
> off to the registered handler.
Bingo, couldn't have said it better myself. :-)
The main advantages to making open() extensible are twofold:
1. No more reinventing the wheel to support new file
types on different platforms or networks.
2. Easy integration so that <> can address files, dirs,
pipes, websites, ipc communications, sockets, rpc...
Not all of the multitude of open() modules needs to or even *should* go
in core. The opposite, in fact. By providing easy hooks for overloading
filehandles you decrease development time and increase portability of
new file methods. The open() modules would be much faster and lighter
weight.
-Nate
