On Fri, Aug 18, 2000 at 10:07:06AM -0400, Jerrad Pierce wrote:
> >Also, your examples don't cover this:
> >   $web = open "http://www.yahoo.com", GET;
> >Remember, additional args for the proposed open handler can follow the
> >filename.
> Never saw it. How many additional arg's?

As many as it takes.

>       Maybe you should go with named parameters for object mode then.
>       For those into OO, this makes more sense than positional parameters
>       anyways, no?

There is no "object mode", there are just filehandles like always.
You can call them "objects" if you like and use them as such, but then
you can also always use them in ways you are used to.

        $fh = open "filename";
        while (<$fh>) {
           ...
        }

>        Also, if you're going to support URL's
>        (I guess RFC 100 would go in as well then)
>        Umm what read methods are you going to do on a URL other than GET?

That's up to the module that implements the semantics for opening
URLs.  Perl should come with a reasonable default, but we have to
take this step before we can make that one.

BTW, mostly this proposal just extends the filename parsing that perl
already does so that this:

        $fh = open "http://www.perl.com", OTHERARGS;

is really shorthand for something like this:

        use http;
        $fh = http->open("http://www.perl.com", OTHERARGS);

Where "http" could be anything.

>        PROPFIND would be an opendir
>        PUT would be open >http:// or >>http://
>        POST would be problematic perhaps >-http:// ?

This is still up for grabs I think.  I believe that any filenames that
start with one of the special characters of traditional open() should
assume the user is opening a file of that name.  To get GET, PUT, POST,
whatever, those should be arguments to the open-handler.

        # For example
        $fh = open "http://www.perl.com", { mode => 'GET' };    # http->open()

        $fh = open ">http://www.perl.com";      # traditional open()
                                                # trys to make a file called
                                                # http://www.perl.com

But, that's just my take.

>        We'd need/want Perl with builtin SSL then which would be
>        non-exportable!

"need"?  Not at all!  "want"?  Perhaps.  But that's what CPAN is for.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Reply via email to