Re: RFC 14 (v3) Modify open() to support FileObjects and
On Mon, Aug 14, 2000 at 03:01:54PM -0700, Nathan Wiger wrote:
or less verbose,
$fh = open "http://my.homepage.com";
This is still up in the air. I think this will probably end up doing a
GET via the http handler on the webpage specified. That seems the most
natural, since you'd probably want these to work the same:
open http "http://www.yahoo.com"; # GET
open "http://www.yahoo.com"; # GET also
Random thoughts:
open "http://www.perl.com";
open "http://www.perl.com?foo=barbaz=blat";
open "http://www.perl.com", %args;
open "http://www.perl.com", { mode = 'POST' }, %args;
Hmm. I think that "modes" should be made explicit rather than relying
on special characters fore or aft of the "filename". Especially since
the individual handlers get to decide how they want to treat that
filename.
I'd say any "filename" that starts with the usual open-special
characters should take the rest of the string as a literal filename on
the local system.
Which makes it consistent with these, which you'd assume would work the
same:
open "/var/log/mylog";
open "file:///var/log/mylog";
open "file:///var/log/mylog", { mode = 'APPEND' };
Here's a translation of the last http and the above file opens:
http-open("http://www.perl.com", { mode = 'POST' }, %args);
file-open("file:///var/log/mylog", { mode = 'APPEND' });
What do you think?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 14 (v3) Modify open() to support FileObjects and
What does that mean? When the handler is invoked, what does it see?
$fh = open myhttp "http://www.perl.com", "fred", "barney";
Does that result in a call like this?
myhttp::open("http://www.perl.com", "fred", "barney");
Exactly. Or to be "more correct"
myhttp-open("http://www.perl.com", "fred", "barney");
Why strip anything? Just pass the string to the handler verbatim. It
would certainly seem weird to me if URI-handlers got something
different than other special-purpose handlers.
imagine
http::open("www.perl.com", "fred", "barney"); # weird
myhttp::open("http://www.perl.com", "fred", "barney");
/imagine
That's fine by me. I'm going to put out an RFC today on embedding full
URI support, since nobody has yet. We can discuss this more then.
If no handler by that name has been
registered, undef is returned.
Where are these handlers registered? How are they registered? In my
mind I was thinking that we could just name our handlers as packages
so that
$fh = open "http://www.perl.com"; # and
$fh = open myhttp "http://www.perl.com";
would cause Perl to search @INC for http.pm and myhttp.pm and auto-use
them.
Basically, you're right. I'll have an RFC out later today on handlers
and pseudo-classes. A handler is just = 1 class. The RFC on AUTOLOAD
being able to decline a request? Same idea. Think Apache handler. All
will become "clear" soon... :-) :-) :-)
-Nate
Re: RFC 14 (v3) Modify open() to support FileObjects and
# Open a remote webpage
$http = open http "http://www.perl.com/", GET;
^
1) The URL says that it's a http resource, so why do we have
to tell open to use a http handler?
a) Allows custom handlers:
open myhttp "http://www.perl.com/";
b) Handles stuff without requiring URI syntax:
open dir "C:\Windows\System"; # the "C:" handler?
2) We are opening it for input ("If MODE is '' or nothing,
the file is opened for input." -- perlfunc), so why do we
have to tell open to use the GET method?
Fine with me - here's a stab at http MODES:
= GET# optional
= PUT
+ = POST
= HEAD # ??
-Nate
