Re: Perl6 burns 18% fewer calories
Michael Hendricks wrote: In other words, Huffman coding works and Perl6 hackers had better start watching their waistlines. Or maybe we should spin it that Perl6 helps reduce global warming ;) Anyway, I collected a small sample (~300 lines each) of Perl5 code along with equivalent Perl6 code. Some came from the Exegeses and others from Pugs' SVN. I had Text::TypingEffort give me some pseudo-scientific results and typing the Perl5 code takes about 18% more physical effort than typing the Perl6 code. My god! What is this wonderful module of which you speak? Finally a chance to help in the argument that ideas that try to force less characters in a huffman-inspired nightmare might make life worse from a actually typing it in real life sense. I wonder if handles different keyboard, I'd like to the differences in using Perl between the different country keyboards. Especially those poor nordics with the / and $ in funny places :) Adam K
Re: DBI v2 - The Plan and How You Can Help
Oh drat - not the DBI connection string discussion again! On 7/4/05, Darren Duncan [EMAIL PROTECTED] wrote: 5. All details used to construct a connection handle should be completely decomposed rather than shoved into an ungainly data source. Examples of what should be distinct (not all being applicable at once) are: 1. the DBI driver module to use; 2. the internet server IP address or domain name and port; 3. the locally defined server device socket; 4. the locally defined service (eg, ODBC or SQL*Net) name; 5. the file system file name; 6. the file system directory name; 7. some other detail if any for fully in-RAM databases; 8. the authorization identifier / user name; 9. the password; 10. some other authorization credential, or channel encryption details, or whatever else; 11. what kind of database or what database product is being used, if known. If the DBI driver talks to a client-configurable DBI proxy server, then, it should be possible to nest a set of the above settings (eg, as a hash-ref) as one part of the main settings given to the proxy client. Only 1, 8 and 9 (driver name, user ID, password) apply to Informix databases - and you've missed out the other bit that applies - the database name, and optionally database server name hosting it (either 'dbase' or '[EMAIL PROTECTED]'). These are not the same as 2, 3, 4, 5, 6, 7, 10, or 11, and I can't think how any of them (except perhaps 10) could be applied to an IDS connection. Oh, and if you're going to enhance the connection, please ensure you cover challenge-response protocols (where you send an initial username/password and the authentication server comes back with a question such as what is the number on your RSA key fob at the moment, and the hapless user has to type that information in, and the connection management code has to deal with this - callbacks and the like. So, as was discussed emphatically and exhaustively (in January 2005 in dbi-dev under 'Proposing an API for the extension for simplifying database connections'), this is not readily going to fly with the existing DBMS - specifically, not with IDS. Closed-source DBMS are *not* necessarily going to adapt to meet the needs of Perl and DBI. You can argue that's their loss - you may even be right. But you'll be limiting the acceptability of Perl + DBI in some respects. You'll also be annoying the hell out of me if you can't define a connection string that will work with Informix (I'm not too worried about the challenge-response stuff, though Informix can handle that). Oh - and DBI v2 should have support for scrollable cursors. -- Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h Guardian of DBD::Informix - v2005.01 - http://dbi.perl.org I don't suffer from insanity - I enjoy every minute of it.
Re: DBI v2 - The Plan and How You Can Help
In particular, the DBI must not mandate impossible levels of support from the drivers. It will benefit you nothing if the DBI is immaculate and wonderful and incredibly all-singing and all-dancing, but no-one can write a driver for it because the requirements cannot be met by the actual DBMS that Perl + DBI needs to work with. I concur. Like CPAN as a whole, DBI's strength is in it's complete and near universal coverage of all databases, and insanely great (and occasisionally greatly insane) drivers that do strange and wonderful things. If we start sacrificing drivers by raising the bar too high, DBI as a whole suffers. Anyone proposing new features for DBI needs to be extremely careful of CYJ syndrome. Can't You Just (or sometimes Could You Just) syndrome is described here. http://c2.com/cgi/wiki?CouldYouJust http://www.oreillynet.com/pub/wlg/3593 http://c2.com/cgi/wiki?JustIsaDangerousWord Go read them now. I'll wait... This sort of behaviour can play a big part in ending up with second system problems. I have an increasing suspicion that having open design processes like the Tim's call for comments plays a big part in it as well. People are free to comment on things that 1) They won't have to implement themselves and (in some cases, but not you Duncan) 2) They think they know what they are talking about, but really have no idea what it means underneath the surface. In any case, I still propose that DBI2 split the driver interface into Roles. The main DBI2::Role::Transport role does ONLY what DBI does best now. That is, connecting to the database, preparing and sending queries, and fetching the results. Forget the current -tables interface. Drivers can OPTIONALLY implement the DBI2::Role::Schema interface to handle interrogation of the database schema. The current way we handle it is really messy by my standards, and could use a dedicated interface. As you invent major new features for DBI2, implement them roles. DBI2::Role::Transational, DBI2::Role::RFC90210 (the super flashy Beverly Hills feature), etc etc. Exactly what these roles should be I don't want to state with any certainty. That's the sort of thing that Tim, with his complete understanding of the issues, should be doing on his own. But I _would_ certainly like to see schema/table stuff separated from the base connection/query functionality. While I'm on the topic of DBI, one other feature I'd like to see would be something like better support for large objects or various types. In my personal DBI wrapper I've been using plain SCALAR refs as parameters to signify a BLOB, so I can pass by reference without a copy of a potentially large memory chunk, and then having to do driver-specific translation to bind variables (Oracle) or what have you. Some base way of default method defining a BLOB object (whether provided in memory, or pointing at a file handle to pull the data from at commit time) in would be really nice. Even if the way I have to pass the blobs to each driver differs, I'd like to be at least be able to say, This is a DBI2::Data::BLOB object (or something functionally equivalent). Adam K
Re: DBI v2 - The Plan and How You Can Help
On Sat, 2005-07-09 at 01:22 -0700, Jonathan Leffler wrote: Oh drat - not the DBI connection string discussion again! On 7/4/05, Darren Duncan [EMAIL PROTECTED] wrote: 5. All details used to construct a connection handle should be completely decomposed rather than shoved into an ungainly data source. Examples of what should be distinct (not all being applicable at once) are: 1. the DBI driver module to use; 2. the internet server IP address or domain name and port; 3. the locally defined server device socket; 4. the locally defined service (eg, ODBC or SQL*Net) name; 5. the file system file name; 6. the file system directory name; 7. some other detail if any for fully in-RAM databases; 8. the authorization identifier / user name; 9. the password; 10. some other authorization credential, or channel encryption details, or whatever else; 11. what kind of database or what database product is being used, if known. If the DBI driver talks to a client-configurable DBI proxy server, then, it should be possible to nest a set of the above settings (eg, as a hash-ref) as one part of the main settings given to the proxy client. Only 1, 8 and 9 (driver name, user ID, password) apply to Informix databases - and you've missed out the other bit that applies - the database name, and optionally database server name hosting it (either 'dbase' or '[EMAIL PROTECTED]'). These are not the same as 2, 3, 4, 5, 6, 7, 10, or 11, and I can't think how any of them (except perhaps 10) could be applied to an IDS connection. There are certainly database-specific things to be worked around. An improvement to the current DSN scheme would be a URI, as discussed in the past. The leading dbi: on every DSN is redundant, so a URI might look like this: driver://user:[EMAIL PROTECTED]:port/instance Oh, and if you're going to enhance the connection, please ensure you cover challenge-response protocols (where you send an initial username/password and the authentication server comes back with a question such as what is the number on your RSA key fob at the moment, and the hapless user has to type that information in, and the connection management code has to deal with this - callbacks and the like. Seconded, with request for support of SSL client certificate authentication. -jwb
Re: DBI v2 - The Plan and How You Can Help
On 7/9/05, Darren Duncan [EMAIL PROTECTED] wrote:
At 1:22 AM -0700 7/9/05, Jonathan Leffler wrote:
On 7/4/05, Darren Duncan [EMAIL PROTECTED] wrote:
5. All details used to construct a connection handle should be
completely decomposed rather than shoved into an ungainly data
source. Examples of what should be distinct (not all being
applicable at once) are: 1. the DBI driver module to use; 2. the
internet server IP address or domain name and port; 3. the locally
defined server device socket; 4. the locally defined service (eg,
ODBC or SQL*Net) name; 5. the file system file name; 6. the file
system directory name; 7. some other detail if any for fully in-RAM
databases; 8. the authorization identifier / user name; 9. the
password; 10. some other authorization credential, or channel
encryption details, or whatever else; 11. what kind of database or
what database product is being used, if known. If the DBI driver
talks to a client-configurable DBI proxy server, then, it should be
possible to nest a set of the above settings (eg, as a hash-ref) as
one part of the main settings given to the proxy client.
Only 1, 8 and 9 (driver name, user ID, password) apply to Informix
databases -
Re-read that paragraph. It says 'not all being applicable at once'.
Yes - I realized that.
and you've missed out the other bit that applies - the database
name, and optionally database server name hosting it (either 'dbase'
or '[EMAIL PROTECTED]'). These are not the same as 2, 3, 4, 5, 6, 7, 10,
or 11, and I can't think how any of them (except perhaps 10) could
be applied to an IDS connection.
I think that 2 thru 4 cover this, though I used more generic language
I don't. The server name in IDS is not a host name or domain name, nor is it
a port number (so 2 is not applicable), nor is it the locally named socket
(so 3 is not applicable), nor is it the locally defined service (so 4 is not
applicable).
All of these are identified by, but are distinct from, the IDS server name.
There is a mechanism (configuration file) that hides all the gory details
from the user. Users should not need to know sordid details like port
numbers, or whether the host is on an IPv4 or IPv6 network, etc.
Further, within an IDS instance, there are multiple databases that can be
separately connected to - '[EMAIL PROTECTED]', '[EMAIL PROTECTED]', '
[EMAIL PROTECTED]', '[EMAIL PROTECTED]'. You must be able to specify the
database
within the server instance.
Now, in fact, server1 and server2 could be alternative names for the same
hunk of disk space, supervised by the same IDS instance but with different
connection properties - such as encrypted vs unencrypted - but that is
probably just too confusing. Equally, and more normally, server1 could be on
a wholly different machine from server2.
[Concrete example: I have many IDS instances running on my machine at work.
One instance has 4 names:
anubis_17, anubis_17_tcp, anubis_17_str, anubis_17_shm. The first two are
both network connections - albeit usually using loopback since I usually
work on the same machine. The third uses a STREAMS pipe; the fourth uses
shared memory. All allow me to connect to the same set of databases, which
includes 'sysmaster', 'sysutils', 'stores', 'logged', 'unlogged',
'mode_ansi'. Each of those databases has its own independent set of system
catalogs. I can connect to '[EMAIL PROTECTED]' or '[EMAIL PROTECTED]' and
edit the same data - it's the same database, identified by different server
names and different connection properties. I also have another IDS instance,
running an older version of IDS, with server names anubis_23, anubis_23_tcp,
anubis_23_str, anubis_23_shm - and the same set of databases, but only
because some of them are standard and the others I keep there to make
testing DBD::Informix easier. I also have an entry configured for a database
server called 'smartpts' that is based in Lenexa, KS - I work in Menlo Park,
CA - about 1800 miles away. I can run $db1 = DBI-connect('
dbi:Informix:[EMAIL PROTECTED]'); $db2 = DBI-connect('
dbi:Informix:[EMAIL PROTECTED]'); to connect to those databases. I can also, in
general, do distributed queries between the two databases without explicitly
connecting to the other. And note that I can switch between TCP and SHM
connections on the local machine (which is
anubis.menlo.ibm.comhttp://anubis.menlo.ibm.com)
simply by changing the server name - I don't have to do any other
modifications to the connection string.]
Please note that for Informix, the database name (optionally with server
name) is all you need to specify. (There's an environment variable that
specifies the default server name if you omit it.) Specifying a 'host name'
won't work; there is no mechanism for connecting by specifying a host name -
except as part of the configuration file. Specifying a port number (or
service name) won't work; there is no mechanism for connecting by specifying
a port
Re: DBI v2 - The Plan and How You Can Help
Jonathan Leffler wrote: I dunno which DBMS support prepare without a database connection, but I would expect all the mainstream databases to require a database connection. +1 I'm also far from convinced that there's any significant benefit in separating the 'create a database handle' from the 'connect to database server' part. +1 Not to mention the effect, that one major charm of DBI is its simplicity: Connect, Execute for updates, inserts, or deletes and Connect, Execute, Fetch for select. I can't see an advantage in overly extending the interface. Jochen
Re: DBI v2 - The Plan and How You Can Help
Jeffrey W. Baker skribis 2005-07-09 11:27 (-0700): Oh drat - not the DBI connection string discussion again! There are certainly database-specific things to be worked around. An improvement to the current DSN scheme would be a URI, as discussed in the past. The leading dbi: on every DSN is redundant, so a URI might look like this: driver://user:[EMAIL PROTECTED]:port/instance I think URIs are the right way to go, and one of the very few things PHP (though be it with PEAR) did right. http://pear.php.net/manual/en/package.database.db.intro-dsn.php It would be fun if we could just steal that design and build on top of it, for compatibility, but also because other people have already thought about it and proven that it works. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: DBI v2 - The Plan and How You Can Help
At 10:25 PM +1000 7/9/05, Adam Kennedy wrote: In any case, I still propose that DBI2 split the driver interface into Roles. The main DBI2::Role::Transport role does ONLY what DBI does best now. That is, connecting to the database, preparing and sending queries, and fetching the results. Forget the current -tables interface. Drivers can OPTIONALLY implement the DBI2::Role::Schema interface to handle interrogation of the database schema. The current way we handle it is really messy by my standards, and could use a dedicated interface. As you invent major new features for DBI2, implement them roles. DBI2::Role::Transational, DBI2::Role::RFC90210 (the super flashy Beverly Hills feature), etc etc. Exactly what these roles should be I don't want to state with any certainty. That's the sort of thing that Tim, with his complete understanding of the issues, should be doing on his own. That sounds like a great idea and a good starting place on which to build certain design issues. In fact, I have already been implementing something similar to that in my 'Rosetta' database access library for over a year now. It has a concept of feature support lists where each Rosetta Engine/driver must take a standard fine-ish-grained checklist and programmatically declare which list items it officially supports. An application can see what an Engine/driver claims to support before trying to use it, and will know whether or not the Engine/driver can meet its needs or not. An Engine's/driver's declaration can be read by invoking the features() method of some Rosetta Interface objects. An additional use for this feature is that a comprehensive common test suite for all Engines/drivers can consult features() prior to running its tests so that it can skip any tests that an Engine/driver doesn't claim to support; it will only invoke and pass/fail features that the Engine/driver claims to support. See the Rosetta::Details documentation section 'FEATURE SUPPORT VALIDATION' for the main summary of feature support lists. But I _would_ certainly like to see schema/table stuff separated from the base connection/query functionality. I agree. When you get down to it, schema/table/etc reverse engineering is a very complicated and involved process. Fetching lists of tables or columns etc should no more be built in than SQL parsing or generating. In short, anything that can normally be fetched or changed using ordinary SQL statements should be left out of the DBI core; let wrappers do that stuff through the SQL pipe that DBI provides. This said, it is still very useful for DBI to provide a function for fetching a list of auto-detectable data sources, so that should stay. On a similar note, utility functions like quote() should be left out of the DBI core, and left to either a separate module or someone's wrapper, since it's firmly related to SQL generation. If people want DBI itself to handle stuff like that for them, they should use host parameters for the literals in question. While I'm on the topic of DBI, one other feature I'd like to see would be something like better support for large objects or various types. I second that. Have API methods for fetching or storing by-the-chunk pieces of LOBs that one could not do with a traditional bind_param() etc since the whole thing won't fit in RAM at once. -- Darren Duncan
Re: DBI v2 - The Details - :name for placeholders
At 9:27 PM -0700 7/10/05, Jonathan Leffler wrote: This is not what DBI deals with - it deals more nearly with the CLI syntax, where that is not, as far as I know, permitted. My impression of DBI is that it is a stand-in of sorts for a SQL CLI, and does or should do all of the same sorts of things. Each time you run a SQL statement, it is like typing said statement into a CLI. (In fact, I seem to recall that DBI ships with a simple SQL CLI program that runs on top of it, and that has an almost 1:1 mapping.) DBI abstracts the CLI a bit by providing things like connect() methods rather than having users execute 'CONNECT TO ...' SQL, but that doesn't really change what I've said. So DBI is basically the same as CLI but that it is easier for programmers to use by replacing an input terminal with functions. In that context, the :foo syntax corresponds to what bind_var() etc maps to. If anyone wants to use my hyperlinked HTML version of the standard SQL syntax, let me know and I'll make it available for download on a website. I updated it last week, so the version I have at home isn't current (though most people wouldn't notice the change - it was very minor and solely related to formatting). Please do that. So far I have had the drudgery of manually scrolling through a 1000+ page PDF document to look up things. Your version should be much faster. This said, does it include what page in the original the info came from, so I can correlate them in reference documentation? -- Darren Duncan
