From darren at DarrenDuncan.net Mon Nov 1 17:31:46 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Mon Nov 1 17:31:55 2004 Subject: [VPM] November meeting topic Message-ID: A proper writeup will be posted in about a week, but meanwhile ... I'm happy to say that I am now far enough along with my database portability toolkit that I should be able to talk about it as the November meeting topic. Note that I will be publishing a more wide-spread announcement of the toolkit's availability prior to the Victoria-pm specific writeup; you will get a copy of that first. -- Darren Duncan From Peter at PSDT.com Mon Nov 1 17:44:02 2004 From: Peter at PSDT.com (Peter Scott) Date: Mon Nov 1 17:46:00 2004 Subject: [VPM] November meeting topic In-Reply-To: References: Message-ID: <6.1.2.0.2.20041101154256.02baecb0@shell2.webquarry.com> At 03:31 PM 11/1/2004, Darren Duncan wrote: >I'm happy to say that I am now far enough along with my database >portability toolkit that I should be able to talk about it as the >November meeting topic. Sounds good to me. I'm still swamped wiht move-related issues, but I will be able to attend. I'd like it if someone who attended October would tell me or post to the list a decsription of what happened at the meeting and how it was received. Sorry I had to miss it. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From abez at abez.ca Thu Nov 11 18:13:22 2004 From: abez at abez.ca (abez) Date: Thu Nov 11 18:13:57 2004 Subject: [VPM] Next Lecutre? Message-ID: So what will the next lecture be on? abram -- abez ------------------------------------------ http://www.abez.ca/ Abram Hindle (abez@abez.ca) ------------------------------------------ abez From darren at DarrenDuncan.net Thu Nov 11 18:50:44 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Thu Nov 11 18:50:55 2004 Subject: [VPM] Next Lecutre? In-Reply-To: References: Message-ID: At 4:13 PM -0800 11/11/04, abez wrote: >So what will the next lecture be on? >abram I'll give it, and it will be about my new Perl modules for rigorous database portability, demonstrated in use by an updated version of that trivial Genealogy app from July. I'll post a proper announcement in a few hours. -- Darren Duncan From darren at DarrenDuncan.net Thu Nov 11 22:55:27 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Thu Nov 11 22:55:40 2004 Subject: [VPM] presentation for November 16 meeting Message-ID: You can put the text following the dashed line into the official November announcement, between the time/place paragraph and the "other topics" one. Since it is unusually long, any suggestions for shortening it while retaining the important points are welcome; please post those on the list, so everyone can see them. -- Darren Duncan ------------------ On November 16th of 2004, Darren Duncan will give a sequel to his July 20th presentation, that concerned how to make a trivial genealogy database-manager application using Perl and a SQL database, SQLite to be specific. The November meeting will focus on introducing Darren's new CPAN-registered modules that strive to implement complete and rigorous cross-database portability. The core modules are 'SQL::Routine' and 'Rosetta', plus 'Locale::KeyedText' and 'Rosetta::Engine::Generic'. These modules should help you write database-using applications of any size, that leverage all sorts of advanced database product features, and support trivial (zero change) drop-in substitution between many dozens of database products, such as: SQLite, MySQL, PostgreSQL, Oracle, Sybase, Firebird, DB2, SQL Server, and more. Rosetta is conceptually a DBI wrapper, whose strongest addition is SQL generation, but it also works without DBI, and with non-SQL databases. The module set's goal is similar to Java, where code written with it will run the same way on any platform with zero changes. Its goal is to help free users and developers from database vendor lock-in, such as that caused by the investment in large quantities of vendor-specific code. It also comes with a comprehensive validation suite that proves it is providing identical behaviour no matter what the underlying database vendor is. Darren's modules will be demonstrated in action using a version of the trivial genealogy application that is modified to access the database engine through those modules rather than directly. For simplicity, the demonstration will use the trivial-to-install SQLite database (DBD::SQLite 1.0.7). The same code used in the demonstration will be on CPAN as a 'demo' accompanying the 'Rosetta' module, so it is kept in a working state over time. Note that these modules are still bleeding-edge and pre-alpha; while they will work well enough next week to power the demonstration, most other features are not quite finished yet. From Peter at PSDT.com Fri Nov 12 12:28:44 2004 From: Peter at PSDT.com (Peter Scott) Date: Fri Nov 12 12:31:56 2004 Subject: [VPM] Victoria Perl Mongers meeting November 16 Message-ID: <6.1.2.0.2.20041111174547.02d81a30@shell2.webquarry.com> Victoria.pm will meet at its regular date, time, and place on Tuesday, November 16, 7pm, at UVic. The location is Harry Hickman Building room 120 (the Building Formerly Known As the Centre for Innovative Teaching). See http://uvic.ca for maps if necessary. ----------- Darren Duncan will give a sequel to his July 20th presentation, that concerned how to make a trivial genealogy database-manager application using Perl and a SQL database, SQLite to be specific. The November meeting will focus on introducing Darren's new CPAN-registered modules that strive to implement complete and rigorous cross-database portability. The core modules are 'SQL::Routine' and 'Rosetta', plus 'Locale::KeyedText' and 'Rosetta::Engine::Generic'. These modules should help you write database-using applications of any size, that leverage all sorts of advanced database product features, and support trivial (zero change) drop-in substitution between many dozens of database products, such as: SQLite, MySQL, PostgreSQL, Oracle, Sybase, Firebird, DB2, SQL Server, and more. Rosetta is conceptually a DBI wrapper, whose strongest addition is SQL generation, but it also works without DBI, and with non-SQL databases. The module set's goal is similar to Java, where code written with it will run the same way on any platform with zero changes. Its goal is to help free users and developers from database vendor lock-in, such as that caused by the investment in large quantities of vendor-specific code. It also comes with a comprehensive validation suite that proves it is providing identical behaviour no matter what the underlying database vendor is. Darren's modules will be demonstrated in action using a version of the trivial genealogy application that is modified to access the database engine through those modules rather than directly. For simplicity, the demonstration will use the trivial-to-install SQLite database (DBD::SQLite 1.0.7). The same code used in the demonstration will be on CPAN as a 'demo' accompanying the 'Rosetta' module, so it is kept in a working state over time. Note that these modules are still bleeding-edge and pre-alpha; while they will work well enough next week to power the demonstration, most other features are not quite finished yet. ------------- Other topics to be covered as time permits; make requests for anything particular. I would also like to see a future presentation by someone that can talk about how Perl is being used in a commercial application or something of the same scale that they are familiar with. (Courtesy copy to VLUG members by permission of the list manager. Victoria.pm's home page is .) -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From darren at DarrenDuncan.net Sun Nov 14 01:23:51 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Sun Nov 14 01:24:03 2004 Subject: [VPM] Victoria Perl Mongers meeting November 16 In-Reply-To: <6.1.2.0.2.20041111174547.02d81a30@shell2.webquarry.com> References: <6.1.2.0.2.20041111174547.02d81a30@shell2.webquarry.com> Message-ID: I just updated the web site with the November info. -- Darren Duncan From darren at DarrenDuncan.net Sun Nov 14 01:30:14 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Sun Nov 14 01:30:23 2004 Subject: [VPM] resources needed for Nov meeting In-Reply-To: <6.1.2.0.2.20041111174547.02d81a30@shell2.webquarry.com> References: <6.1.2.0.2.20041111174547.02d81a30@shell2.webquarry.com> Message-ID: If I am going to demonstrate some code in action, or display the code itself, I will need someone to bring a Unix-compatible portable computer with the software on it, and/or internet access. I don't have a portable of my own. Prerequisites: - Perl 5.8 preferred, 5.8.5 is best - DBI 1.45 (the newest) - DBD::SQLite 1.0.7 (the newest) I also need to know when is the latest I can send my code to you, since I may be working on it close to the deadline. Thank you. -- Darren Duncan From darren at DarrenDuncan.net Sun Nov 14 23:28:42 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Sun Nov 14 23:28:52 2004 Subject: [VPM] difficulty getting on VPM list In-Reply-To: <200411142028.59551.sae@uvic.ca> References: <200411142028.59551.sae@uvic.ca> Message-ID: At 8:28 PM -0800 11/14/04, S. Alan Ezust wrote off-list: >Thanks for the personal invitation. I've tried to join the victoria >perlmongers mailing list 3 times now, and I don't get any response. >Looking forward to hearing your talk. >What's up with the mailing list, btw? Alan (and CC'd to VPM so they know about it), I don't know what problem you are having. How have you tried to join the list? And what happened when you did? Below is header info that includes how to join the list. Let me know if you can't understand it. List-Id: "Perl users in or near Victoria, BC" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , -- Darren Duncan From Peter at PSDT.com Mon Nov 15 03:32:00 2004 From: Peter at PSDT.com (Peter Scott) Date: Mon Nov 15 12:06:19 2004 Subject: [VPM] Victoria Perl Mongers meeting tomorrow Message-ID: <6.1.2.0.2.20041112103120.09320200@shell2.webquarry.com> Victoria.pm will meet at its regular date, time, and place tomorrow, Tuesday, November 16, 7pm, at UVic. The location is Harry Hickman Building room 120 (the Building Formerly Known As the Centre for Innovative Teaching). See http://uvic.ca for maps if necessary. ----------- Darren Duncan will give a sequel to his July 20th presentation, which concerned how to make a trivial genealogy database-manager application using Perl and a SQL database, SQLite to be specific. The November meeting will focus on introducing Darren's new CPAN-registered modules that strive to implement complete and rigorous cross-database portability. The core modules are 'SQL::Routine' and 'Rosetta', plus 'Locale::KeyedText' and 'Rosetta::Engine::Generic'. These modules should help you write database-using applications of any size, that leverage all sorts of advanced database product features, and support trivial (zero change) drop-in substitution between many dozens of database products, such as: SQLite, MySQL, PostgreSQL, Oracle, Sybase, Firebird, DB2, SQL Server, and more. Rosetta is conceptually a DBI wrapper, whose strongest addition is SQL generation, but it also works without DBI, and with non-SQL databases. The module set's goal is similar to Java, where code written with it will run the same way on any platform with zero changes. Its goal is to help free users and developers from database vendor lock-in, such as that caused by the investment in large quantities of vendor-specific code. It also comes with a comprehensive validation suite that proves it is providing identical behaviour no matter what the underlying database vendor is. Darren's modules will be demonstrated in action using a version of the trivial genealogy application that is modified to access the database engine through those modules rather than directly. For simplicity, the demonstration will use the trivial-to-install SQLite database (DBD::SQLite 1.0.7). The same code used in the demonstration will be on CPAN as a 'demo' accompanying the 'Rosetta' module, so it is kept in a working state over time. Note that these modules are still bleeding-edge and pre-alpha; while they will work well enough next week to power the demonstration, most other features are not quite finished yet. ------------- Other topics to be covered as time permits; make requests for anything particular. I would also like to see a future presentation by someone that can talk about how Perl is being used in a commercial application or something of the same scale that they are familiar with. (Courtesy copy to VLUG members by permission of the list manager. Victoria.pm's home page is .) -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From darren at DarrenDuncan.net Tue Nov 16 01:01:46 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Tue Nov 16 01:01:55 2004 Subject: [VPM] new info for Nov meet - written module description Message-ID: Below is a rewritten DESCRIPTION for my "Rosetta" module, which will be in the next release that goes up after the meeting. It should be much better than the one currently on CPAN, and may make the module a lot easier to understand. Note that since I am coming down to the wire and still don't have working demo code yet, I may have to sacrifice printed hand-outs, if there ever were going to be any. The following may take the place of one. -- Darren Duncan --------------- The Rosetta Perl 5 module defines a complete and rigorous API for database access that provides hassle-free portability between many dozens of database products for database-using applications of any size and complexity, that leverage all sorts of advanced database product features. The Rosetta Native Interface (RNI) allows you to create specifications for any type of database task or activity (eg: queries, DML, DDL, connection management) that look like ordinary routines (procedures or functions) to your programs, and execute them as such; all routine arguments are named. Rosetta is trivially easy to install, since it is written in pure Perl and its whole dependency chain consists of just 2 other pure Perl modules. One of the main goals of Rosetta is similar to that of the Java platform, namely "write once, run anywhere". Code written against the RNI will run in an identical fashion with zero changes regardless of what underlying database product is in use. Rosetta is intended to help free users and developers from database vendor lock-in, such as that caused by the investment in large quantities of vendor-specific code. It also comes with a comprehensive validation suite that proves it is providing identical behaviour no matter what the underlying database vendor is. The RNI is structured in a loosely similar fashion to the DBI module's API, and it should be possible to adapt applications written to use the DBI or one of its many wrapper modules without too much trouble, if not directly then by way of an emulation layer. One aspect of this similarity is the hierarchy of interface objects; you start with a root, which spawns objects that represent database connections, each of which spawns objects representing queries or statements run against a database through said connections. Another similarity, which is more specific to DBI itself, is that the API definition is uncoupled from any particular implementation, such that many specialized implementations can exist and be distributed separately. Also, a multiplicity of implementations can be used in parallel by the same application through a common interface. Where DBI gives the name 'driver' to each implementation, Rosetta gives the name 'Engine', which may be more descriptive as they sit "beneath" the interface; in some cases, an Engine can even be fully self-contained, rather than mediating with an external database. Another similarity is that the preparation and execution (with place-holder substitution) of database instructions are distinct activities, and you can reuse a prepared instruction for multiple executions to get performance gains. The Rosetta module does not talk to or implement any databases by itself; it is up to separately distributed Engine modules to do this. You can see a reference implementation of one in the Rosetta::Engine::Generic module. The main difference between Rosetta and the DBI is that Rosetta takes its input primarily as SQL::Routine (SRT) objects, where DBI takes SQL strings. See the documentation for SQL::Routine (distributed separately) for details on how to define those objects. Also, when Rosetta dumps a scanned database schema, it does so as SRT objects, while DBI dumps as either SQL strings or simple Perl arrays, depending on the schema object type. Each 'routine' that Rosetta takes as input is equivalent to one or more SQL statements, where later statements can use the results of earlier ones as their input. The named argument list of a 'routine' is analagous to the bind var list of DBI; each one defines what values can be given to the statements at "execute" time. Unlike SQL strings, SRT objects have very little redundancy, and the parts are linked by references rather than by name; the spelling of each SQL identifier (such as a table or column name) is stored exactly once; if you change the single copy, then all code that refers to the entity updates at once. SRT objects can also store meta-data that SQL strings can't accomodate, and you define database actions with the objects in exactly the same way regardless of the database product in use; you do not write slightly different versions for each as you do with SQL strings. Developers don't have to restrict their conceptual processes into the limits or dialect of a single product, or spend time worrying about how to express the same idea against different products. Rosetta is especially suited for data-driven applications, since the composite scalar values in their data dictionaries can often be copied directly to RNI structures, saving applications the tedious work of generating SQL themselves. Rosetta is conceptually a DBI wrapper, whose strongest addition is SQL generation, but it also works without the DBI, and with non-SQL databases; it is up to each Engine to use or not use DBI, though most will use it because the DBI is a high quality and mature platform to build upon. The choice between using DBI and using Rosetta seems to be analagous to the choice between the C and Java programming languages, respectively, where each database product is analagous to a hardware CPU architecture or wider hardware platform. The DBI is great for people who like working as close to the metal as possible, with direct access to each database product's native way of doing things, those who *want* to talk to their database in its native SQL dialect, and those who want the absolute highest performance. Rosetta is more high level, for those who want the write-once run-anywhere experience, less of a burden on their creativity, more development time saving features, and are willing to sacrifice a modicum of performance for the privilege. There exist on CPAN many dozens of other modules or frameworks whose modus operandi is to wrap the DBI or be used together with it for various reasons, such as to provide automated object persistence functionality, or a cross-database portability solution, or to provide part of a wider scoped application tool kit, or to generate SQL, or to clone databases, or generate reports, or provide a web interface, or to provide a "simpler" or "easier to use" interface. So, outside the DBI question, a choice exists between using Rosetta and one of these other CPAN modules. Going into detail on that matter is outside the scope of this documentation, but a few salient points are offered. For one thing, Rosetta allows you to do a lot more than the alternatives in an elegant fashion; with other modules, you would often have to inject fragments of raw SQL into their objects (such as "select" query conditionals) to accomplish what you want; with Rosetta, you should never need to do any SQL injection. For another point, Rosetta has a strong emphasis on portability between many database products; only a handful of other modules support more than 2-3 database products, and many only claim to support one (usually MySQL). Also, more than half of the other modules look like they had only 5-20 hours of effort at most put into them, while Rosetta and its related modules have likely had over 1000 hours of full time effort put into them. For another point, there is a frequent lack of support for commonly desired database features in other modules, such as multiple column keys. Also, most modules have a common structural deficiency such that they are designed to support a very specific set of database concepts, and adding more is a lot of work; by contrast, Rosetta is internally designed in a heavily data-driven fashion, allowing the addition or alternation of many features with little cost in effort or complexity. Perhaps a number of other CPAN modules' authors will see value in adding back-end support for Rosetta and/or SQL::Routine to their offerings, either as a supplement to their DBI-using native database SQL back-ends, or as a single replacement for the lot of them. Particularly in the latter case, the authors will be more freed up to focus on their added value, such as object persistence or web interfaces, rather than worrying about portability issues. As quid quo pro, perhaps some of the other CPAN modules (or parts of them) can be used by a Rosetta Engine to help it do its work. Please see the Rosetta::Framework documentation file for more information on the Rosetta framework at large. It shows this current module in the context of actual or possible other components. From Peter at PSDT.com Fri Nov 19 11:20:21 2004 From: Peter at PSDT.com (Peter Scott) Date: Fri Nov 19 11:20:32 2004 Subject: [VPM] December and January meetings Message-ID: <6.1.2.0.2.20041119091511.02de0540@shell2.webquarry.com> I propose cancelling the December Perl Mongers meeting, being that it would fall on the 21st. For the January meeting, I have an idea for something lighter: a round table dissection of SelfGOL, the program Damian Conway calls the epitome of Perl Worst Practices, or (insert Australian accent) "*really* Extreme Programming." See http://damian.conway.org/Courses/WorstPractice.html: -------------- The SelfGOL program can: * self-replicate by printing its own source code, * rewrite other Perl programs to allow them to self-replicate their own source code too, * detect and report the small number of Perl programs that are not rewritable in this way, * transform itself or other Perl programs into cellular automata of arbitrary size and play Conway's "Game of Life", * animate any short text as a cycling marquee banner. SelfGOL accomplishes these feats in under 1000 bytes of standard Perl, without importing any modules, and without using a single if, unless, while, until, for, foreach, goto, next, last, redo, map, or grep. --------------- Damian gives a half-day presentation on how to understand this program, so we may not finish, but I have seen his short version of that talk and it is... entertaining. -- Peter Scott Pacific Systems Design Technologies http://www.perldebugged.com/ *** New! *** http://www.perlmedic.com/ From darren at DarrenDuncan.net Fri Nov 19 14:32:29 2004 From: darren at DarrenDuncan.net (Darren Duncan) Date: Fri Nov 19 14:32:40 2004 Subject: [VPM] December and January meetings In-Reply-To: <6.1.2.0.2.20041119091511.02de0540@shell2.webquarry.com> References: <6.1.2.0.2.20041119091511.02de0540@shell2.webquarry.com> Message-ID: At 9:20 AM -0800 11/19/04, Peter Scott wrote: >I propose cancelling the December Perl Mongers meeting, being that >it would fall on the 21st. >For the January meeting, I have an idea for something lighter: a >round table dissection of SelfGOL, the program Damian Conway calls >the epitome of Perl Worst Practices, or (insert Australian accent) >"*really* Extreme Programming." See >http://damian.conway.org/Courses/WorstPractice.html: I'm fine with that idea. -- Darren Duncan