-----Original Message-----
From: Dan Sugalski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 1:41 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Load paths
At 6:32 PM +0000 3/24/04, [EMAIL PROTECTED] wrote:
>Dan wrote:
>> At the moment I'm thinking of the load path as an array of subs that
>> get passed in the file being looked for and return... something. I'm
>> not sure what, though.
>
>Don't reinvent the wheel here. Obviously what should be return is an URI.
>If we start off only supporting "file://..." okay, but eventually we
>should support full over-the-net URI's (http:, https:, ftp:, etc.).
The full-over-the-net URI stuff in the core's in the "Over Dan's dead
body" category. :) Not gonna happen so long as I hold the hat.
If people want to root their own machine for other folks that's fine,
but they're going to have to go to some trouble to do it.
--
Dan makes a very important point here. This doesn't seem like
functionality which should be built into the core of Parrot; however, one
could make an argument that it should support something like the following:
Parrot Extension for File Opening/Loading:
1. Instruct Parrot to Load a particular URI handler (ftp,
http, smb, etc, etc...)
2. Instruct Parrot to Open a *file* on this URI (or perform
some other appropriate I/O related operation)
3. URI Handler modules should implement a particular set of
methods. Any method they cannot due should return something to indicate so "as
opposed to failure on something it should be able to do".
4. There should be nothing in the core of Parrot I/O except
the concept of loading a URI module and using it (as opposed to the default of
"local file")
Parrot Extension for arbitrary MIME-Type Query/Result Set:
1. Instruct Parrot to Load a particular MIME-Type (or even
something more abstract) handler
- Type could include things like: XLM Document,
DocBook Document, HTML Document, SQL Datasource, XML Database, LDAP Database,
BerkleyDB database, MS-Word Document, Gnumeric Spreadsheet, etc, etc, etc,
etc...
2. Handlers should implement a Query/Result-Set interface
- Queries should be simply text strings -- let the
individual handler define how the query should look
- Queries could also be done via a standardized
mini-query language or a X/Open-like Query API
- Results Sets should return as particular types of
collections depending upon the module (it should be discoverable from the API
what type of collection will be returned): Array, Hash, Array of Hashs, Tree,
etc, etc, etc....
Now, applications should then be able to do something like (and this
is serious pseudo-code):
my $fh = new File::URIHandler ( "FTP",
"[EMAIL PROTECTED]:/home/gbutler/my-document.txt" );
foreach $line ( $fh->getlines() )
{
print $line, "\n";
}
$fh->close;
my $query = new Query::Handler ( "ODBC",
"PostgreSQL:My-DB:My-UName:My-Passwd" );
my @rows = $query->execute ( "select * from customers where
customer-id between 3 and 10" );
foreach $row ( @rows )
{
print $row->{'customer-name'}, " : ",
$row->{'phone-no'}, "\n";
}
$query->close;
$query = new Query::Handler ( "GNUMERIC",
"file://my-spreadsheet.xml" );
my @cube = $query->execute (
"cells(A4-Sheet1:D32-Sheet1:A4-Sheet3)" );
foreach my $plane ( @rows )
{
foreach my $row ( $$plane )
{
foreach my $cell ( $$row )
{
print $cell->value, " : ",
$cell->formula, "\n";
}
}
}
$query->close;
Now, I realize this all looks like stuff which should be implemented
as Objects of the particular language. But, it could just as well be
represented as loose-wrappers at the language level around Parrot Opcodes
and/or Objects provided as a Parrot Loadable Extension/Module.
Is this complete CRACK!!! or is this something that should be
considered?
The information contained in this e-mail message is privileged and/or
confidential and is intended only for the use of the individual or entity
named above. If the reader of this message is not the intended recipient,
or the employee or agent responsible to deliver it to the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this communication in error, please immediately notify us by telephone
(330-668-5000), and destroy the original message. Thank you.
