perldb-developers

Re: [pdb-dev]Preliminary Thoughts on PerlDB module structure

[<Ran...@Ho...>]

This is really good. All these areas must be addressed if we are to avoid
multiple reworking of the code. A good RDBMs system is complex beastie. Thanks
Jonathan!

Jonathan writes:

Trouble-Maker ExtraOrdinaire at Work Again!

Here are some notes I jotted down over a period of several days,
without actually managing to make the complete (by a large margin).
Take with a large dose of salt (or alcohol or other more pleasurable
substance).  I think some of the basic ideas are sound; a few are
definitely verging on the unorthodox (see the Random Thoughts section
at the bottom).  I debated trying to make them into some HTML with
hyperlinks all around, but ran out of time -- again.  I probably won't
be answering any questions or issues until the weekend at the earliest.
.
.
.
.

[pdb-dev]Preliminary Thoughts on PerlDB module structure

[Jonathan L. <jle...@ea...>]

Trouble-Maker ExtraOrdinaire at Work Again!

Here are some notes I jotted down over a period of several days,
without actually managing to make the complete (by a large margin).
Take with a large dose of salt (or alcohol or other more pleasurable
substance).  I think some of the basic ideas are sound; a few are
definitely verging on the unorthodox (see the Random Thoughts section
at the bottom).  I debated trying to make them into some HTML with
hyperlinks all around, but ran out of time -- again.  I probably won't
be answering any questions or issues until the weekend at the earliest.

I apologize if the formatting is squiffy with long lines; I blame the
Redmond Monopolist and/or their major victim (Win95 or Netscape).

--
Jonathan Leffler (jle...@in..., jle...@ea...)
Guardian of DBD::Informix v1.00.PC1 -- see http://www.perl.com/CPAN
#include <disclaimer.h>

----------

How Should PerlDB Look

Two Options:

1. Integrated into Application (IIA)
 Pro: Simple
 Con: Less resilient (app crashes; database has crashed)
 Con: Less secure (general purpose applications can't all be made SUID
or SGID)
 Pro: Avoids overhead of IPC
 Con: Network access to database more difficult
 Con: Scalability is limited (every program loads all the database code)

2. Separate Database Server (SDS)
 Pros and Cons are the converses of the list above

PerlDB needs to get some code working.  With a modicum of care, it will
be
possible to provide the IIA solution first and the SDS solution in a
subsequent
release with minimal to no changes in the applications.

Modules:

DBD::PerlDB  - DBI-compatible PerlDB module

 Either one of the connect parameters could indicate whether to use IIA
or SDS, or
the first release could use IIA and the second (or some subsequent)
release could
use SDS.

PerlDB::ODBC  - Perlized ODBC interface
 The DBD::PerlDB module has to call down onto some PerlDB code,
somehow.  Since
the goal is compatability with the ANSI standard, it seems logical that
the
interface should be based on ODBC (SQL-CLI).  It should, however, be
convenient
for Perl since PerlDB is meant to be a pure Perl database.  For the IIA
version,
the PerlDB::ODBC code would call directly onto the core PerlDB modules. 
For the
SDS version, the PerlDB::ODBC code would serialize the request and
convey it
through a comms layer to the driver.

-----------

Storage Access Management

One of the important chunks of the PerlDB will be the storage access
management.
Since SQL includes variable length data types, the storage management
will
ultimately be based on  variable-length records rather than fixed length
records.
However, fixed length record systems are easier to design, and may be a
sensible
choice for a first version.  The services provided by the storage access
manager
should be defined so that both fixed length and variable length records
can be
handled.  Since these are complex systems to code, there could
conceivably be
several versions of the PerlDB storage management code.  Let's
hypothesize that
the storage management module is PerlDB::SAM.  We can hypothesize two
initial
variants: a text system which encodes the control information in
readable text,
and a binary system which encodes the control information in a more
compressed
format.  The text system can be used for easier debugging of the data,
and the
binary system should, in principal, be more economical on disk space.

PerlDB::SAM  - Switching code to access a real access method

PerlDB::SAM::Binary - Binary Storage Access Manager

PerlDB::SAM::Text - Text Storage Access Manager

-----------

Data Types

Another important chunk of the PerlDB will be the type handling code. 
As far as
possible, the code in the SAM should be independent of the types of the
data in
the records.  Certain standard types will have to be implemented, but it
should be
possible for a user to add new types to the DBMS.  Further, these types
should be
indexable when applicable, and indexability should be an interrogatable
attribute
of the type.  Consequently, there will need to be standard interfaces
for types.
Part of this will probably be a hash with references to the methods used
for a
particular type.  Other information about the type can also be included
in the
hash:

 {
 'indexable' => 1,
  'fixed length' => 4,
 'binary to text' => \&converter1,
 'text to binary' => \&converter2,
 'comparator' => \&comparator
 ...
 }

In point of detail, the presence or absence of a comparator is probably
sufficient
to indicate whether a type is indexable, at least for simple B-Tree
indexes.  More
complex indexing strategies (R-Trees) can wait later developments;
adding new
indexing strategies to  the storage manager is yet another level of
complexity
which can wait even longer.

It will be necessary to define which elements can be present in the hash
for a
type  Further, the hash must be extensible by a type designer, so there
needs to
be a name-space in the keys reserved for the PerlDB system and another
name-space
reserved to the type designer.

PerlDB::Type  - Access control to PerlDB types

PerlDB::Type::Varchar - Implementation of VARCHAR type

PerlDB::Type::Numeric - Implementation of NUMERIC type

PerlDB::Type::Date - Implementation of DATE type

-----------

Outline of SAM storage strategies

Fixed length records can be identified by position in the file rather
easily.  A
record number multiplied by the length of the record indicates where the
record
can be found in the file.  Further, updating a record never requires the
record to
be relocated on disk; the same size of slot is always sufficient.

For sequential access to variable length records, each record should
(probably) be
prefixed by its actual length.  In a binary system, the encoding of the
length
could take a leaf out of the UTF-8 encoding scheme.  Record lengths
0..127 (2^7-1)
bytes would be represented by a single byte (with, by definition, a
top-bit of
zero).  Record lengths 128..16383 (2^14-1) bytes would be represented by
two
bytes, the first having the top two bits set to 10 and the actual length
encoded
in the rest, with suitable extensions for larger sizes.  The maximum
record length
should not be smaller than 32 kB without extreme provocation.  In a text
system,
the length of the record would be presented as a number with a delimiter
to
separate the length from the data.  Additionally, since a record can be
invalid
because it was deleted, you can use different delimiters to indicate a
valid
record and an invalid record.  Since a record only has one of two states
- invalid
or valid - it may be possible to include this single bit of information
in the
record length encoding in a binary system.  Even a fixed length record
scheme
needs some indicator of whether a record is valid or not.  C-ISAM uses a
trailing
character to indicate this; '\n' if the record is valid and '\0' if it
is
deleted.  If nothing else, the record validity marker allows a program
to validate
the data file in case the index information is corrupted.

Inspired by Informix's C-ISAM, I envisage that the storage for a single
PerlDB
table will be in two (or more) separate operating system files (one data
file, and
either one index file for all indexes or one index file per index). 
There are,
indubitably, many alternatives.  These include the one file per table
mechanisms
supported by the xDBM and the 'one file (typically a raw disk device)
containing
parts
of many tables' used by Informix OnLine and IDS, etc.

The scope of the SAM probably includes physical data storage, locking
and
transaction logging.  Could you provide separate PerlDB::SAM::Locking
and
PerlDB::SAM::Logging modules?  Conceivably, but they would be so closely
related
to the PerlDB::SAM::Storage (Text or Binary) code that they would
probably not be
independently replaceable.  Note that there would need to be recovery
code to
restore the database to a valid state after a crash of any sort. 
Further, since
the recovery code itself could be halted unexpectedly, the requirements
are
complex and include idempotent REDO and UNDO operations (so that UNDO(x)
has the
same effect as UNDO(UNDO(x)), etc -- see C J Date 'Introduction to
Database
Systems, Vol 2', for example, or Bernstein, Hadzilacos, Goodman
'Concurrency
Control and Recovery in Database Systems').

-----------

Where does the SQL::Parser fit in?

The SQL::Parser module will be called by the control code in the
database when the
request is one of a very limited set of choices (primarily prepare,
possibly a
couple of others, such as execute immediate).  When invoked, it will be
given a
string, and from that string, it will generate some sort of parse tree. 
After the
parser returns the parse tree, the system will decide what to do next. 
It will
have to validate any references to database objects (does the table,
column, ...
exist, and similar questions), which requires access to the system
catalog
(PerlDB::Catalog).  If everything is valid, then the result might be
passed to
some function which acts more or less directly on the state of the
database or the
program -- an example might be CREATE TABLE which gets on with creating
a table
(more work for the system catalog code, of course).  There isn't
anything like
optimization to be done really.  Or it might be something interesting
like a
SELECT, INSERT...SELECT, UPDATE or DELETE statement which needs to be
optimized to
achieve acceptable performance.  This type of statement will be handed
off to the
optimizer.  The optimizer will deduce which strategies can be used to
obtain the
requisite answer, and will apply some algorithm (possibly heuristic,
possibly by
computing the cost of the different options) to choose a strategy for
executing
the statement.

I envisage that the PerlDB::Optimizer will end up producing a set of
Perl subs
which will be eval'd and then used to execute the query operations.  The
set might
consist of a single sub, or the set might have three members (an
initializer, an
iterator, and a finalizer) or more.  The query executor will then invoke
the
functions in sequence as requested by the  program accessing the
database,
returning results as required.  Note that the functions will need to
store state
in between calls, in general.  One advantage of the Perl subs being
eval'd is that
you can print them out to see what the query is doing.  This should be a
huge boon
during the debugging process.  The subroutines generated by the
optimizer might be
stored so that if the same query was initiated by multiple people (or
multiple
times in a single program), the cached functions could be reused.  These
might
even be stored in the system catalog.

The Informix cost-based query optimizer has two options: SET
OPTIMIZATION {LOW |
HIGH}.  With the value set to LOW, the optimizer evaluates a set of
possible
initial steps in an answering the question, and assumes that the one
with the
lowest cost is the one to use, and subsequently explores the second
steps only for
the single chosen first step.  With the value set to HIGH, it evaluates
all
options at every step, and finally uses the most cost beneficial.  I've
always
wanted to be able to use SET OPTIMIZATION 10, for instance, to say
"evaluate the
cost of all the possible first steps, and choose the most efficient 10
options; at
the next stage, evaluate all the alternatives and choose the 10 with the
least
cost; iterate until the best cost is established".  This seems likely to
be a
reasonable alternative to the overly restrictive LOW and the
unrestricted HIGH
costs.  Another option would be "SET OPTIMIZATION 50 PERCENT", where the
optimizer
would choose half (50%) of the alternatives at each stage.  This is more
flexible
for smaller queries, where there might only be two or three options at
any stage.
Further, Informix supports a SET EXPLAIN ON option to record the query
plan
actually chosen.  However, you cannot establish which alternatives were
considered
and rejected, nor how the cost estimate has derived.  It would be nice
to be able
to see which alternative plans were considered and rejected.  The
explanation
should be written to a file, but probably by the front-end code rather
than the
server (to simplify life in a distributed database environment; under
Informix,
the file is written on the database server machine).  Further, the name
of the
output file should be configurable (it isn't in Informix).

As has been mentioned elsewhere, the routines used by the optimizer will
need to
interface with the storage access manager.  There will also probably be
a sort
package which should be handled separately, even though it will probably
need the
services of the SAM.

-----------

Random Thoughts

One interesting idea which would need some thought is based on the
observation
that the relational model stipulates that rows are unordered.  If the
user does
not specify an ordering, maybe the database could provide an element of
indeterminacy in the order in which data is returned to the
application.  It might
be as simple as initially selecting 5 rows and returning one at random,
and on
each subsequent fetch, adding a new row to the set and again returning
one at
random.  This would ensure that users did not rely on accidental
ordering of data
from the query execution process.  This is very definitely a refinement,
and you
would need to be able to reinstate determinism when necessary, such as
when making
a problem reproducible.

Re: [pdb-dev]What about Perl-SQL by Andy Glew?

[Andy D. <and...@ya...>]

Hi Tim,

> Someone should talk to the author to see if he's interested in
> joining this project.

Email on the way.  BTW, has anybody had any contact with Jim Turner
of DBD::Sprite?  I've sent a couple of emails to Jim, over the last
couple of weeks, at jim...@lm..., but not yet received any
replies.  And my insecurity paranoia therapist is starting to get
concerned :-)

rgds,
ad.

=====
Pyramid Power
=> http://www.perldb.com

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

Re: [pdb-dev]What about Perl-SQL by Andy Glew?

[Tim B. <Tim...@ig...>]

On Mon, Apr 24, 2000 at 04:25:23PM -0700, Andy Duncan wrote:
> Hi Steve,
> 
> > I just came across this which seems to be some very advanced work
> > in this area of writing a dbms in perl:
> > http://www.cs.wisc.edu/~glew/perl-sql-brief.html
> 
> I've just added this to the links page (and also taken the
> opportunity to tidy this page up a bit to make it a bit easier to
> use):
> 
> => http://perldb.sourceforge.net/links.html

Someone should talk to the author to see if he's interested in
joining this project.

Tim.

Re: [pdb-dev]What about Perl-SQL by Andy Glew?

[Andy D. <and...@ya...>]

Hi Steve,

> I just came across this which seems to be some very advanced work
> in this area of writing a dbms in perl:
> http://www.cs.wisc.edu/~glew/perl-sql-brief.html

I've just added this to the links page (and also taken the
opportunity to tidy this page up a bit to make it a bit easier to
use):

=> http://perldb.sourceforge.net/links.html

rgds,
ad.

=====
Pyramid Power
=> http://www.perldb.com

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

[pdb-dev]What about Perl-SQL by Andy Glew?

[Tolkin, S. <Ste...@fm...>]

I just came across this which seems to be some very advanced work in this
area
of writing a dbms in perl:
http://www.cs.wisc.edu/~glew/perl-sql-brief.html

This supports many of the harder operations: joins (including full outer
join), scalar and aggregate functions, etc.

There is a 26 page document.
I could not find a file with a license, but he does say it is "free".
The perl-sql.tar files contains 407 files, with many regression tests.
Many files contain a comma in their name so I cannot extract those on NT
using winzip.
(But perhaps someone will let me know of another unzip program that lets me
dynamically rename during the extract.  Or I'll go to Unix when I get a
tuit.)
 
Hopefully helpfully yours,
Steve
-- 
Steven Tolkin          ste...@fm...      617-563-0516 
Fidelity Investments   82 Devonshire St. R24D    Boston MA 02109
There is nothing so practical as a good theory.  Comments are by me, 
not Fidelity Investments, its subsidiaries or affiliates.

RE: [pdb-dev] Backends

[Garrett G. <ga...@sc...>]

Andy,

From: Andy Duncan [mailto:and...@ya...]
>
> Having said all this, and got my $0.02 cents worth, maybe the only
> successful route will be to plan all the modules out in advance, as
> you suggest?

Perhaps it is just that my AR Factor (anal-retentive) is high ;) -But yes, I
do find myself dwelling on trying to nail down the big picture.  Not the
tiny little details, just the big picture. I don't want to discourage people
from bathing in the tide pools of creation and innovation... -I'm trying to
get a handle on the scope of the project.

I think defining a scaffolding of generic modules and interfaces will be
indespensible when it comes down to constructing swappable modules. Perl,
Python, Linux, Apache, all the successful open source projects have their
benevolent dictators responsible for overall architecture and grand design.
"Cathedral", "Bazaar", buzzwords aside, the interfaces aren't going to be
very robust and the modules very swappable if there isn't some up front
planning. I hope I'm not alone, but I need an architect to provide a
blueprint, a roadmap, or merely a finger pointing that-a-way.

Tim Bunce (self-described part-time PerlDB architect) I apologize, but I'm
about to go on a rampage reposting your prior comments regarding interfaces
and modules:

Tim Bunce wrote:
> I agree. This is a big project. Defining multiple modules and
> especially the API's between them will be key to success.

Tim Bunce wrote:
> I believe PerlDB should be two things:
> 1/ An _architecture_ consisting of a set of module API's.
> 2/ One (or more) example implementations of that architecture

Tim Bunce wrote:
> Some random thoughts:
> 
> 1/ There's little point in getting into long discussions about the
>    fine details of functionality and implementation at this stage.
>    We'll just loose focus.
> 
> 2/ I think the primary goal of PerlDB should be Well Defined Modularity.
> 
> 3/ Well Defined Modularity will enable (just about) everyone to make
>    PerlDB be whatever they want it to be.
> 
> 4/ It should be possible to plug in different query parsers, client
>    communications, storage managers, query optimisers, security managers
>    etc etc.
>
> 5/ The key to Well Defined Modularity is Well Defined Interfaces.
> 
> 6/ Well Defined Interfaces are hard and require thought and discussion.
> 
> 7/ Effort currently going into "1" above should be directed into
>    "how can we define the module API's to make what I want possible".
> 
> 8/ "Release Early and Release Often" implies that we should set our
>    sights at a quickly reachable target first and build from there.
> 
> Rather than make a particular proposal for a "quickly reachable target"
> at this point I'd like to invite discussion on the points above first.
> Please keep it short if you can, for my sake.

Tim Bunce wrote:
(in reference to Jeff Zucker's SQL::Statement place in PerlDB)
> Your "Statement Handler" will need to be 'exploded' into lots of
> modules. Most of which will have no knowledge of the DBI or DBD's.

Garrett

RE: [pdb-dev] Backends

[Andy D. <and...@ya...>]

Hi Garrett,

> This keeps coming up... but we have yet generate even a list of
> modules and interfaces.
> Can anyone take a shot at componentizing a database and a list of
> interfaces between the components with a short description of each?

You'll have to forgive me, as I'm the least technical person on these
lists (and my lawyers are standing by to contest this), but I've
recently been reading up on John Ousterhout's creation of Tcl/Tk. 
What sort of sparked Tcl/Tk off, was Macintosh's release of
Hypercard, a superb monolithic cathedralesque graphical GUI toolkit. 
He realised that he'd never be able to match it, so what he decided
to do was build up a series of tiny tools, one module at a time, as
he and his students couldn't compete with a thousand fulltime
Macintosh developers.  What resulted, Tcl/Tk, quickly eclipsed
Hypercard, and is now far more widely used.

I'm under no illusions that PerlDB, or any database driven by Perl,
is in no way a foregone conclusion, and like Tim suggested earlier,
could be very prone to collapse in an embarrased heap, if we take any
wrong turns on a long twisting journey.

However, instead of getting stuck on this long journey, perhaps we
should take a leaf out of Dr Ousterhout's book, and instead of
designing a huge monolithic Perl database cathedral, we just add bits
on, one API at a time, and take a hundred different routes to the
solution.  This way, if one evolutionary pathway folds, there'll be
ten others to take its place.  If 'it', the database, eventually
succeeds, this will be an entirely revolutionary database, and will
not look like anything that has gone before.  Where the currently
established paths are basically derived from one or two rival schools
of thought within the database development department of Berkeley
University (Hypercard models), taken over the water of San Francisco
bay via the graduates to one or two Route 101 companies, what we do
will be driven by one or two hundred contesting/co-operating, maybe a
few thousand, people, over the internet.  Therefore to predict what
proteins and nucleic acids arise from the soup of this discussion, is
perhaps impossible.  So why even try?  Why not just go on and try and
stick these pieces together in interesting patterns, and see if any
life emerges?

We have an embarrasment of riches in our Perl database world, Tim and
Alligator's DBI, all the DBD modules, Jeff Zucker's parser, RAM
engine, DBD::Sprite, and a host of other wonderful pieces of
software.  It will simply be criminal if we let all these fantastic
pieces of work just continue to help make people like Larry Ellison,
Bill Gates, Steve Ballmer, and all the other suits at Sybase and
Informix richer and richer, while we, the people who are holding all
of these empires together in one way or another, don't manage to put
these pieces together in a way which is better than anything that has
gone before.  I truly believe, despite my earlier pessimism, that we
will do this, though I won't pin myself to a timeframe.  I just don't
think we can plan right now how exactly we're going to do it.  Let's
just eat that old Elephant, one piece at a time.

> Critique
> your hearts out, suggest improvements, clarify vagueries, suggest
> sub-modules, etc.

What you, Shawn and others are doing, to port Gadfly to Perl, is a
superb effort.  And I'm really looking forward to seeing 0.01 of
Botfly jump off the shelves, and 1.45 (or whatever) take the world by
storm.  I hope it's so good,  the rest of our efforts melt away, and
we all join the shebang under the "Botfly" banner.  But in case it
doesn't work out, let's build a few other tunnels, in case Jerry
unroofs the ones we've got.  But who knows what these tunnels will
look like, and whether we'll be in the trees, when we come out at
midnight?

Having said all this, and got my $0.02 cents worth, maybe the only
successful route will be to plan all the modules out in advance, as
you suggest?  Go for it!  I don't even know what colour shirt I'll be
wearing tomorrow :-)

Just my $0.02 cents.

Rgds,
AndyD

PS. Heck, this is a difficult business.  Sometimes I think "Oh heck,
let's just help keeping making Oracle easier and easier to use, and
forget this Perl database nonsense".  But this is what Wormtongue
would've done to help Saruman and Sauron.  Aragorn and Olorin
would've tried to build PerlDB.

=====
Pyramid Power
=> http://www.perldb.com

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

RE: [pdb-dev] Backends

[Garrett G. <ga...@sc...>]

From: Tim Bunce [mailto:Tim...@ig...]
> 
> > Jeff Zucker wrote:
> >
> > At this point it's more a matter of thinking
> > about which features we want in the long run
> > as well as which ones are currently available.
> 
> And how to *define an API* to the underlying *Storage Manager* that
> enables *both* these modules *and many others* to be used.

This keeps coming up... but we have yet generate even a list of modules and
interfaces. 

Can anyone take a shot at componentizing a database and a list of interfaces
between the components with a short description of each? 

What follows if the best architectural overview I've found so far. If anyone
has read the book, please feel free to give a review. Lets get some comments
on the following as it applies to the architecture of a Perl DBMS. Critique
your hearts out, suggest improvements, clarify vagueries, suggest
sub-modules, etc.

Readings in Database Systems, 3rd Edition
Stonebraker & Hellerstein, eds.
(http://redbook.cs.berkeley.edu/lec2.html)

Relational System Architecture

Disk management choices: 
- file per relation 
- big file in file system 
- raw device 

Process Model: 
- process per user 
- server 
- multi-server 

Basic modules: 
- parser 
- query rewrite 
- optimizer 
- query executor 
- access methods 
- buffer manager 
- lock manager 
- log/recovery manager 

Query Rewriter 
- Flattens views (why?) 
- may change query semantics (constraints,
  protection, etc.) 

Optimizer 
- large space of equivalent relational plans 
- pick one that's going to be "optimal" (?) 
- produces either an interpretable plan tree, or
  compiled code 

Executor 
- modules to perform relation operations like
  joins, sorts, aggregations, etc. 
- calls Access Methods for operations on base
  and temporary relations 

Access Methods 
- uniform relational interface (open, get next),
  a la INGRES AMI, System R's RSS 
- multiple implementations: heap, B-tree, 
  extensible hashing 

Buffer Manager 
- Intelligent user-level disk cache 
- must interact with transaction manager & lock
  manager 

Lock Manager 
- must efficiently support lock table 
- System R architecture influential: 
- physical and logical locks treated uniformly 
- multiple granularity of locks 
- set intent locks at high levels 
- deadlock handling: detection 

Log/Recovery Manager 
- "before/after" log on values 
- checkpoint/restore facility for quick recovery 
- Redo/Undo on restore 
- Support soft crashes off disk, hard crashes off
  tape. 
- System R's shadowing is too slow. Use 
  Write-Ahead Logging! (WAL) More on this to come. 
- Hard to get right! 

Re: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan Needed

[Andy D. <and...@ya...>]

Hi Tim,

> Simplicity will probably win out here. I'd go for simple and
> direct:
> 
> 	THE PERL DATABASE

Oh, you're no fun :-)

It does have a certain air of inevitability about it though, dammit. 
Ok, ya got me again.

I'll go with this for now, in the reply back to O'Reilly.  Thanks to
everyone else for their ideas on this.  I'm sure we can work them all
into future tags and slogans.  I'm certainly going to try with
"Pyramid Power"! :)

Rgds,
AndyD

=====
Pyramid Power
=> http://www.perldb.com

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

[pdb-dev]Gods of Egypt

[Hugo L. C. <hug...@ya...>]

Here's a cute list of Gods and Godesses of Egypt I
found somewhere on the net (don't remember):

http://www.colba.net/~casanova/perldb/gods_egypt.txt

Could be interesting!

Hugo.

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

Re: [pdb-dev]Anubis-0.02 Available to View

[Andy D. <and...@ya...>]

Hi Jeff,

> Absolutely fab!  Great job Andy and Hugo!

Glad you like it.  Please let me know of any further ideas for
improvement.  In the meantime, Sgt. Bilko has just come on, and Ernie
has to make $35 dollars last for a weekend in Hollywood.

Gotta see how he does it! 8)

laters,
ad.

=====
Pyramid Power
=> http://www.perldb.com

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

Re: [pdb-dev]Anubis-0.02 Available to View

[Jeff Z. <je...@vp...>]

Andy Duncan wrote:
> 
> Anubis-0.02 now available to view (should be available to download
> shortly).  You can access it here:
> 
> => http://perldb.sourceforge.net/cgi-bin/anubis-0.02/anubis.pl
> 

Absolutely fab!  Great job Andy and Hugo!

-- 
Jeff

[pdb-dev]Anubis-0.02 Available to View

[Andy D. <and...@ya...>]

Hi Everyone,

Anubis-0.02 now available to view (should be available to download
shortly).  You can access it here:

=> http://perldb.sourceforge.net/cgi-bin/anubis-0.02/anubis.pl

This address is also held on the front page.

Rgds,
AndyD

PS. Nice One, Hugo! :-)

=====
Pyramid Power
=> http://www.perldb.com

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

Re: [pdb-dev]Re: [Perldb-developers] Scoping PerlDB for brain-dead ISPs

[Andy D. <and...@ya...>]

Hi Jeff,

> I'm obviously not the person to do it, but we should have an
> impartial
> comparison of DBD::Sprite and DBD::RAM as the back end here.  I am
> chagrined to say I haven't looked at DBD::Sprite yet (it's high on
> my
> to-do list though).  Some of the advantages and disadvantages that
> DBD::RAM has and I don't know if DBD::Sprite does are 

I'm even more ashamed to admit that I haven't looked at *either* yet,
I've been too busy reading a precious First Edition of "The Crane
Bag" by Robert Graves :-)

> <shameless plug> that it handles any kind of parseable file,
> regardless
> of format; that it is built to be extendable to other formats; that
> it
> can transparently 'mix and match' tables from many formats; that it
> is
> directly based on SQL::Statement so its syntax will grow in direct
> correlation with the growth of SQL::Parser; that it has built-in
> prototyping and testing facility ... </shameless plug>

Sold! :)

Anubis-0.02 should be out really soon.  It's a long way from getting
to either Sprite or RAM though, yet, but it's growing on me.  Let me
know what you think when you see it?
 
Rgds,
ad.

=====
Pyramid Power
=> http://www.perldb.com

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

[pdb-dev]Motto

[Garrett G. <ga...@sc...>]

Rocky Welch wrote:
> 
> For a motto:
> 
> "I'd walk a mile for PerlDB". ;o)

[Rocky... try not to copy 10+ KB of email in a 2 line post ;)]

Hmm, how about:

1) "it begins with a single step"

Probably too long, but wrapped in a circle you get 3 for the price of 1:
- Standard "it beings with a single step"
- Poetical "with a single step it begins"
- Yoda     "a single step it begins with"


2) "etched in jello"

3) "vini vidi prandi"  (I came, I saw, I ate them for lunch)

4) "vini vidi coemi subucula"  (I came, I saw, I bought the T-shirt)

*) The latin was using an online grammer dictionary...
http://cawley.archives.nd.edu/cgi-bin/lookdown.pl?lunch (I don't know
latin).
Garrett

[pdb-dev]Re: Perldb-developers digest, Vol 1 #37 - 13 msgs

[Rocky W. <roc...@ya...>]

For a motto:

"I'd walk a mile for PerlDB". ;o)

--- per...@li... wrote:
> 
> Send Perldb-developers mailing list submissions to
> 	per...@li...
> 
> To subscribe or unsubscribe via the web, visit
> 	http://lists.sourceforge.net/mailman/listinfo/perldb-developers
> or, via email, send a message with subject or body 'help' to
> 	per...@li...
> You can reach the person managing the list at
> 	per...@li...
> 
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of Perldb-developers digest..."
> 
> 
> Today's Topics:
> 
>   1. Update on Camel Logo Use, Looking Good, Slogan Needed (Andy Duncan)
>   2. Re: Re: [Perldb-developers] Scoping PerlDB for brain-dead ISPs
> (Andy Duncan)
>   3. Re: Update on Camel Logo Use, Looking Good, Slogan Needed (Hugo L.
> Casanova)
>   4. Re: Update on Camel Logo Use, Looking Good, Slogan Needed (Andy
> Duncan)
>   5. RE: Update on Camel Logo Use, Looking Good, Slogan Neede
>  d (Garrett Goebel)
>   6. RE: Update on Camel Logo Use, Looking Good, Slogan Needed (David E.
> Wheeler)
>   7. RE: Update on Camel Logo Use, Looking Good, Slogan Neede d (Andy
> Duncan)
>   8. Re: Re: [Perldb-developers] Scoping PerlDB for brain-dead ISPs (Tim
> Bunce)
>   9. Re: Update on Camel Logo Use, Looking Good, Slogan Needed (Tim
> Bunce)
>   10. Re: Re: [Perldb-developers] Scoping PerlDB for brain-dead ISPs
> (Jeff Zucker)
>   11. Re: Update on Camel Logo Use, Looking Good, Slogan Needed (Hugo L.
> Casanova)
>   12. Re: Update on Camel Logo Use, Looking Good, Slogan Needed (Hugo L.
> Casanova)
> 
> --__--__--
> 
> Message: 1
> Date: Thu, 20 Apr 2000 02:09:05 -0700 (PDT)
> From: Andy Duncan <and...@ya...>
> To: per...@li...
> Subject: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan Needed
> 
> Hi Everyone,
> 
> I'm currently in an email discussion with O'Reilly, where they're
> happy for us to use a "Programming Republic of Perl" type logo (see
> here http://republic.perl.com/logo.html ) in the near-term future
> with some slight restrictions such as having a link to their pages
> and stuff, but best of all, they may also create a slight variation
> for us, with Pyramids in the background, instead of the Palm tree.
> 
> They'd like to know what wording we'd like around our new badge
> variation.  For an example of this, you might want to see the
> http://www.perl.com badge in the top-left corner of the Perl home
> page, available here:
> 
> => http://www.perl.com/pub
> 
> Assuming we have 'www.perldb.com' in black wrapping around the bottom
> of the circle, my suggestions for the top bit in blue, to kick this
> off, are:
> 
> #1: Let's Go Build a Database! 
> 
> (perhaps too long to wrap round circle?)
> 
> #2: Pyramid Power!
> 
> :-)
> 
> #3: Errr...can't think of a third one.  I like "Pyramid Power!", ...
> I know, how about something a bit more forceful and under-stated,
> like ..... errr ...... "Pyramid Power" 8)
> 
> I'd like to get back to O'Reilly pretty soon on this, so we can keep
> moving, and I'm sure this is alterable in the future, but any other
> ideas?
> 
> laters,
> ad.
> 
> =====
> Pyramid Power
> => http://www.perldb.com
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
> 
> --__--__--
> 
> Message: 2
> Date: Thu, 20 Apr 2000 02:39:53 -0700 (PDT)
> From: Andy Duncan <and...@ya...>
> Subject: Re: [pdb-dev]Re: [Perldb-developers] Scoping PerlDB for
> brain-dead ISPs
> To: Jim Lynch <jw...@sg...>, per...@li...
> 
> Hi Jim,
> 
> > I'm coming in pretty late in this discussion, but I went through an
> > evaluation of existing databases a while back and seemed to
> > remember
> > that the Berkley DB had an unacceptable licensing requirement.  I
> > don't remember the details, but I don't think we want to get 
> > in bed with a product without looking at the licensing issues.
> 
> I think we've sort of come round to the consensus that people are
> going to work on their own modules, to help themselves, their own
> interests, and their users needs, but keep PerlDB at the back of
> their mind, so we can build up a collection of modules which we can
> slot together in a sort of dynamic jigsaw at a later date.
> 
> These modules will be plug-in-and-play, and rely on various APIs
> which we come up with, so a Berkeley storage module, if it were
> adopted and developed by someone, can be replaced with another module
> following the same API, should the need arise.
> 
> You may be particularly interested in the "Botfly" project, to port
> Python's "Gadfly" database to Perl, ie. a Pure-Perl solution.  You
> can contact Garrett Goebel about that here:
> gg...@us...
> 
> 4WIW, I'm personally going to try and build a web frontend to Jeff
> Zucker's developing SQL::Parser module, and at the appropriate time,
> bolt on a DBD::Sprite database storage mechanism onto the back end
> (or something).  Not pretty, but someone else might be able to do
> something with it later, to avoid non-Perl alternatives?
> 
> You're right though about licensing issues.  I've heard that
> mSQL/MySQL have licensing issues too?  This
> avoidance-of-licensing-issues idea, I suspect, may be one of the
> background threads which drove us towards the idea of Perl database
> originally?
> 
> Thanks for the warning.  You wouldn't be able to dig out what these
> potential Berkeley licensing issues for us at all?  It could be
> useful to resolve this to avoid a baby-and-bathwater situation.
> 
> Rgds,
> andyd
> 
> PS. BTW Garrett, if you're reading this, I seem to recall that the
> original Greek mother Goddess, Hera, turned one of Zeus's pretty
> girlfriends, Io, into a white cow.  She then created a Gadfly to
> sting this cow and chase her away from Zeus's clutches.  And where
> did she chase her?  Egypt of course! :-)
> Project Io? (input/output?) Incidentally, I also recall one of Hera's
> main chief priestesses (known as the Pythoness - I'm not kidding) was
> based at the Oracle complex at Delphi.  It's a shame someone else has
> already got Project Oracle, as a database name, but thought this
> might be of interest - I've gotta stop reading these Robert Graves
> mythology books so late at night :)
> 
> =====
> Pyramid Power
> => http://www.perldb.com
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
> 
> --__--__--
> 
> Message: 3
> Date: Thu, 20 Apr 2000 07:08:41 -0700 (PDT)
> From: "Hugo L. Casanova" <hug...@ya...>
> Subject: Re: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan
> Needed
> To: Andy Duncan <and...@ya...>
> Cc: perldb-dev <per...@li...>
> 
> --- Andy Duncan wrote:
>  
> > #1: Let's Go Build a Database! 
>  
> I loved this one! It's so... I love it!
> But :
> > (perhaps too long to wrap round circle?)
> We'll have to check it out.
> 
> > #2: Pyramid Power!
> 
> Is pretty powerfull two.
> 
> I have no new idea, but still thinking.........
> 
> 
> Hugo.
> 
> BTW I'm completely fanatic, I worked yesterday on a
> logo for Anubis.
> http://www.colba.net/~casanova/perldb/anubis.html to
> check it out (will be up in a couple of minutes).  And
> I've made a page for all the diferent logos I've done
> so far for PerlDB: http://www.colba.net/~casanova/perldb/index.html
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
> 
> --__--__--
> 
> Message: 4
> Date: Thu, 20 Apr 2000 07:43:03 -0700 (PDT)
> From: Andy Duncan <and...@ya...>
> Subject: Re: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan
> Needed
> To: "Hugo L. Casanova" <hug...@ya...>
> Cc: perldb-dev <per...@li...>
> 
> Hi Hugo,
> 
> > BTW I'm completely fanatic, I worked yesterday on a
> > logo for Anubis.
> > http://www.colba.net/~casanova/perldb/anubis.html 
> 
> Good shot, Sir! Looks fantastic :-)
> 
> I was going to mess about with a British Museum guidebook, a scanner,
> and the Gimp.  But what you've done's better than anything this
> would've resulted in.  Look out for Anubis-0.02, at a website near
> you real soon.  If it's Ok with you, it may come complete with a
> stylish logo you may recognise.
> 
> Rgds,
> AndyD
> 
> =====
> Pyramid Power
> => http://www.perldb.com
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
> 
> --__--__--
> 
> Message: 5
> From: Garrett Goebel <ga...@sc...>
> To: "'Andy Duncan'" <and...@ya...>,
> "Hugo L. Casanova"
> <hug...@ya...>
> Cc: perldb-dev <per...@li...>
> Subject: RE: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan
> Neede
> d
> Date: Thu, 20 Apr 2000 10:02:35 -0500
> charset="iso-8859-1"
> 
> Hugo's logos are nice...
> 
> Io sounds like a nice name for Botfly once it becomes more than a Python
> port of Gadfly.
> 
> For the O'Reilly logo, maybe we could build on the pyramid idea and the
> interchangable building blocks philosophy.
> 
> Or hey, this is Perl... anyone got any Tolkien references? Forging the
> rings, Sauron and the Mount of Doom.
> 
> Garrett
> 
> 
> > -----Original Message-----
> > From: Andy Duncan [mailto:and...@ya...]
> > Sent: Thursday, April 20, 2000 9:43 AM
> > To: Hugo L. Casanova
> > Cc: perldb-dev
> > Subject: Re: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan
> > Needed
> > 
> > 
> > Hi Hugo,
> > 
> > > BTW I'm completely fanatic, I worked yesterday on a
> > > logo for Anubis.
> > > http://www.colba.net/~casanova/perldb/anubis.html 
> > 
> > Good shot, Sir! Looks fantastic :-)
> > 
> > I was going to mess about with a British Museum guidebook, a scanner,
> > and the Gimp.  But what you've done's better than anything this
> > would've resulted in.  Look out for Anubis-0.02, at a website near
> > you real soon.  If it's Ok with you, it may come complete with a
> > stylish logo you may recognise.
> > 
> > Rgds,
> > AndyD
> > 
> > =====
> > Pyramid Power
> > => http://www.perldb.com
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Send online invitations with Yahoo! Invites.
> > http://invites.yahoo.com
> > 
> > _______________________________________________
> > Perldb-developers mailing list
> > Per...@li...
> > http://lists.sourceforge.net/mailman/listinfo/perldb-developers
> > 
> 
> --__--__--
> 
> Message: 6
> From: "David E. Wheeler" <Da...@Wh...>
> To: "'Andy Duncan'" <and...@ya...>,
> "'Hugo L. Casanova'" <hug...@ya...>
> Cc: "'perldb-dev'" <per...@li...>
> Subject: RE: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan
> Needed
> Date: Thu, 20 Apr 2000 08:48:52 -0700
> charset="US-ASCII"
> 
> Andy Duncan Wrote:
> > Hi Hugo,
> >
> > > BTW I'm completely fanatic, I worked yesterday on a
> > > logo for Anubis.
> > > http://www.colba.net/~casanova/perldb/anubis.html
> >
> > Good shot, Sir! Looks fantastic :-)
> 
> I have only one request for this (or any other) logo: DON'T letter-space
> lowercase! I've been influenced by my graphic designer wife, who quotes
> a
> famous graphic designer to the affect that anyone who letter-spaces
> lowercase letters would steal sheep.
> 
> Otherwise, it looks pretty cool to me, too!
> 
> David
> 
> 
> --__--__--
> 
> Message: 7
> Date: Thu, 20 Apr 2000 08:56:27 -0700 (PDT)
> From: Andy Duncan <and...@ya...>
> Subject: RE: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan
> Neede d
> To: Garrett Goebel <ga...@sc...>,
> "Hugo L. Casanova" <hug...@ya...>
> Cc: perldb-dev <per...@li...>
> 
> Hi Garrett,
> 
> > Io sounds like a nice name for Botfly once it becomes more than a
> > Python port of Gadfly.
> 
> And nicely classically linked via the Gadfly/Io story (though I'm
> hoping I haven't got confused with Europa, another one of Zeus's
> floozies).  Plus you get all sorts of nice badges on a white bovine
> type theme.
> 
> laters,
> ad.
> 
> =====
> Pyramid Power
> => http://www.perldb.com
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
> 
> --__--__--
> 
> Message: 8
> Date: Thu, 20 Apr 2000 16:28:24 +0100
> From: Tim Bunce <Tim...@ig...>
> To: Andy Duncan <and...@ya...>
> Cc: Jim Lynch <jw...@sg...>, per...@li...
> Subject: Re: [pdb-dev]Re: [Perldb-developers] Scoping PerlDB for
> brain-dead ISPs
> Organization: Paul Ingram Group, Software Systems, +44 1 483 862800
> 
> On Thu, Apr 20, 2000 at 02:39:53AM -0700, Andy Duncan wrote:
> > Hi Jim,
> > 
> > > I'm coming in pretty late in this discussion, but I went through an
> > > evaluation of existing databases a while back and seemed to
> > > remember
> > > that the Berkley DB had an unacceptable licensing requirement.  I
> > > don't remember the details, but I don't think we want to get 
> > > in bed with a product without looking at the licensing issues.
> > 
> > [...]
> > 
> > Thanks for the warning.  You wouldn't be able to dig out what these
> > potential Berkeley licensing issues for us at all?  It could be
> > useful to resolve this to avoid a baby-and-bathwater situation.
> 
> I believe there is no problem. From the DB_File docs:
> 
>    Here are are few words taken from the Berkeley DB FAQ (at
>    http://www.sleepycat.com) regarding the license:
> 
>      Do I have to license DB to use it in Perl scripts?
> 
>      No. The Berkeley DB license requires that software that uses
>      Berkeley DB be freely redistributable. In the case of Perl,
>      that software is Perl, and not your scripts. Any Perl scripts
>      that you write are your property, including scripts that make
>      use of Berkeley DB. Neither the Perl license nor the Berkeley
>      DB license place any restriction on what you may do with
>      them.
> 
> 
> Tim.
> 
> --__--__--
> 
> Message: 9
> Date: Thu, 20 Apr 2000 16:35:26 +0100
> From: Tim Bunce <Tim...@ig...>
> To: Andy Duncan <and...@ya...>
> Cc: per...@li...
> Subject: Re: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan
> Needed
> Organization: Paul Ingram Group, Software Systems, +44 1 483 862800
> 
> On Thu, Apr 20, 2000 at 02:09:05AM -0700, Andy Duncan wrote:
> > Hi Everyone,
> > 
> > I'm currently in an email discussion with O'Reilly, where they're
> > happy for us to use a "Programming Republic of Perl" type logo (see
> > here http://republic.perl.com/logo.html ) in the near-term future
> > with some slight restrictions such as having a link to their pages
> > and stuff, but best of all, they may also create a slight variation
> > for us, with Pyramids in the background, instead of the Palm tree.
> > 
> > They'd like to know what wording we'd like around our new badge
> > variation.  For an example of this, you might want to see the
> > http://www.perl.com badge in the top-left corner of the Perl home
> > page, available here:
> > 
> > => http://www.perl.com/pub
> > 
> > Assuming we have 'www.perldb.com' in black wrapping around the bottom
> > of the circle, my suggestions for the top bit in blue, to kick this
> > off, are:
> > 
> > #1: Let's Go Build a Database! 
> > #2: Pyramid Power!
> > #3: Errr...can't think of a third one.  I like "Pyramid Power!", ...
> > I know, how about something a bit more forceful and under-stated,
> > like ..... errr ...... "Pyramid Power" 8)
> > 
> > I'd like to get back to O'Reilly pretty soon on this, so we can keep
> > moving, and I'm sure this is alterable in the future, but any other
> > ideas?
> 
> 	GIVE YOUR DATA THE HUMP
> 
> :-)
> 
> Simplicity will probably win out here. I'd go for simple and direct:
> 
> 	THE PERL DATABASE
> 
> Tim.
> 
> --__--__--
> 
> Message: 10
> Date: Tue, 20 Jun 2000 10:56:53 -0700
> From: Jeff Zucker <je...@vp...>
> Organization: -
> To: per...@li...
> Subject: Re: [pdb-dev]Re: [Perldb-developers] Scoping PerlDB for
> brain-dead ISPs
> 
> Andy Duncan wrote:
> 
> > ... at the appropriate time,
> > bolt on a DBD::Sprite database storage mechanism onto the back end
> > (or something). 
> 
> I'm obviously not the person to do it, but we should have an impartial
> comparison of DBD::Sprite and DBD::RAM as the back end here.  I am
> chagrined to say I haven't looked at DBD::Sprite yet (it's high on my
> to-do list though).  Some of the advantages and disadvantages that
> DBD::RAM has and I don't know if DBD::Sprite does are 
> 
> <shameless plug> that it handles any kind of parseable file, regardless
> of format; that it is built to be extendable to other formats; that it
> can transparently 'mix and match' tables from many formats; that it is
> directly based on SQL::Statement so its syntax will grow in direct
> correlation with the growth of SQL::Parser; that it has built-in
> prototyping and testing facility ... </shameless plug>  
> 
> <shamed unplug> Some of its disadvantages are that it does not (yet)
> support typed fields; does not (yet) have authorization mechanisms; does
> not (yet) support transactions; does not (yet) support joins; does not
> (yet) support regex searching within SELECT.  Most of those are in the
> works but they sure ain't there now.</shamed unplug>
> 
> -- 
> Jeff
> 
> --__--__--
> 
> Message: 11
> Date: Thu, 20 Apr 2000 10:59:28 -0700 (PDT)
> From: "Hugo L. Casanova" <hug...@ya...>
> Subject: Re: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan
> Needed
> To: Andy Duncan <and...@ya...>
> Cc: perldb-dev <per...@li...>
> 
> --- Andy Duncan <and...@ya...> wrote:
> > If it's Ok with you, it may come complete with a
> > stylish logo you may recognise.
> > 
> > Rgds,
> > AndyD
> 
> 
> No Problema!
> 
> Just wait a bit I'll do some modifications on it
> according to David E. Wheeler's comment:
> 
> > I have only one request for this (or any other)
> logo: > DON'T letter-space lowercase!
> 
> Witch I agree on!
> 
> Thanks!
> 
> Hugo.
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
> 
> --__--__--
> 
> Message: 12
> Date: Thu, 20 Apr 2000 11:18:26 -0700 (PDT)
> From: "Hugo L. Casanova" <hug...@ya...>
> Subject: Re: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan
> Needed
> To: Andy Duncan <and...@ya...>
> Cc: perldb-dev <per...@li...>
> 
> 
> 
> --- Andy Duncan <and...@ya...> wrote:
> > If it's Ok with you, it may come complete with a
> > stylish logo you may recognise.
> > 
> 
> Go on, i've modified it (take the upper one, with the
> version number!)
> 
> http://www.colba.net/~casanova/perldb/anubis.html
> 
> -->Same URL
> 
> Hugo.
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Perldb-developers mailing list
> Per...@li...
> http://lists.sourceforge.net/mailman/listinfo/perldb-developers
> 
> 
> End of Perldb-developers Digest
> 

=====
Rocky Welch
Oracle DBA Consultant

roc...@ya...

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

Re: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan Needed

[Hugo L. C. <hug...@ya...>]

--- Andy Duncan <and...@ya...> wrote:
> If it's Ok with you, it may come complete with a
> stylish logo you may recognise.
> 

Go on, i've modified it (take the upper one, with the
version number!)

http://www.colba.net/~casanova/perldb/anubis.html

-->Same URL

Hugo.

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

Re: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan Needed

[Hugo L. C. <hug...@ya...>]

--- Andy Duncan <and...@ya...> wrote:
> If it's Ok with you, it may come complete with a
> stylish logo you may recognise.
> 
> Rgds,
> AndyD


No Problema!

Just wait a bit I'll do some modifications on it
according to David E. Wheeler's comment:

> I have only one request for this (or any other)
logo: > DON'T letter-space lowercase!

Witch I agree on!

Thanks!

Hugo.

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

Re: [pdb-dev]Re: [Perldb-developers] Scoping PerlDB for brain-dead ISPs

[Jeff Z. <je...@vp...>]

Andy Duncan wrote:

> ... at the appropriate time,
> bolt on a DBD::Sprite database storage mechanism onto the back end
> (or something). 

I'm obviously not the person to do it, but we should have an impartial
comparison of DBD::Sprite and DBD::RAM as the back end here.  I am
chagrined to say I haven't looked at DBD::Sprite yet (it's high on my
to-do list though).  Some of the advantages and disadvantages that
DBD::RAM has and I don't know if DBD::Sprite does are 

<shameless plug> that it handles any kind of parseable file, regardless
of format; that it is built to be extendable to other formats; that it
can transparently 'mix and match' tables from many formats; that it is
directly based on SQL::Statement so its syntax will grow in direct
correlation with the growth of SQL::Parser; that it has built-in
prototyping and testing facility ... </shameless plug>  

<shamed unplug> Some of its disadvantages are that it does not (yet)
support typed fields; does not (yet) have authorization mechanisms; does
not (yet) support transactions; does not (yet) support joins; does not
(yet) support regex searching within SELECT.  Most of those are in the
works but they sure ain't there now.</shamed unplug>

-- 
Jeff

Re: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan Needed

[Tim B. <Tim...@ig...>]

On Thu, Apr 20, 2000 at 02:09:05AM -0700, Andy Duncan wrote:
> Hi Everyone,
> 
> I'm currently in an email discussion with O'Reilly, where they're
> happy for us to use a "Programming Republic of Perl" type logo (see
> here http://republic.perl.com/logo.html ) in the near-term future
> with some slight restrictions such as having a link to their pages
> and stuff, but best of all, they may also create a slight variation
> for us, with Pyramids in the background, instead of the Palm tree.
> 
> They'd like to know what wording we'd like around our new badge
> variation.  For an example of this, you might want to see the
> http://www.perl.com badge in the top-left corner of the Perl home
> page, available here:
> 
> => http://www.perl.com/pub
> 
> Assuming we have 'www.perldb.com' in black wrapping around the bottom
> of the circle, my suggestions for the top bit in blue, to kick this
> off, are:
> 
> #1: Let's Go Build a Database! 
> #2: Pyramid Power!
> #3: Errr...can't think of a third one.  I like "Pyramid Power!", ...
> I know, how about something a bit more forceful and under-stated,
> like ..... errr ...... "Pyramid Power" 8)
> 
> I'd like to get back to O'Reilly pretty soon on this, so we can keep
> moving, and I'm sure this is alterable in the future, but any other
> ideas?

	GIVE YOUR DATA THE HUMP

:-)

Simplicity will probably win out here. I'd go for simple and direct:

	THE PERL DATABASE

Tim.

Re: [pdb-dev]Re: [Perldb-developers] Scoping PerlDB for brain-dead ISPs

[Tim B. <Tim...@ig...>]

On Thu, Apr 20, 2000 at 02:39:53AM -0700, Andy Duncan wrote:
> Hi Jim,
> 
> > I'm coming in pretty late in this discussion, but I went through an
> > evaluation of existing databases a while back and seemed to
> > remember
> > that the Berkley DB had an unacceptable licensing requirement.  I
> > don't remember the details, but I don't think we want to get 
> > in bed with a product without looking at the licensing issues.
> 
> [...]
> 
> Thanks for the warning.  You wouldn't be able to dig out what these
> potential Berkeley licensing issues for us at all?  It could be
> useful to resolve this to avoid a baby-and-bathwater situation.

I believe there is no problem. From the DB_File docs:

   Here are are few words taken from the Berkeley DB FAQ (at
   http://www.sleepycat.com) regarding the license:

     Do I have to license DB to use it in Perl scripts?

     No. The Berkeley DB license requires that software that uses
     Berkeley DB be freely redistributable. In the case of Perl,
     that software is Perl, and not your scripts. Any Perl scripts
     that you write are your property, including scripts that make
     use of Berkeley DB. Neither the Perl license nor the Berkeley
     DB license place any restriction on what you may do with
     them.


Tim.

RE: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan Neede d

[Andy D. <and...@ya...>]

Hi Garrett,

> Io sounds like a nice name for Botfly once it becomes more than a
> Python port of Gadfly.

And nicely classically linked via the Gadfly/Io story (though I'm
hoping I haven't got confused with Europa, another one of Zeus's
floozies).  Plus you get all sorts of nice badges on a white bovine
type theme.

laters,
ad.

=====
Pyramid Power
=> http://www.perldb.com

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

RE: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan Needed

[David E. W. <Da...@Wh...>]

Andy Duncan Wrote:
> Hi Hugo,
>
> > BTW I'm completely fanatic, I worked yesterday on a
> > logo for Anubis.
> > http://www.colba.net/~casanova/perldb/anubis.html
>
> Good shot, Sir! Looks fantastic :-)

I have only one request for this (or any other) logo: DON'T letter-space
lowercase! I've been influenced by my graphic designer wife, who quotes a
famous graphic designer to the affect that anyone who letter-spaces
lowercase letters would steal sheep.

Otherwise, it looks pretty cool to me, too!

David

RE: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan Neede d

[Garrett G. <ga...@sc...>]

Hugo's logos are nice...

Io sounds like a nice name for Botfly once it becomes more than a Python
port of Gadfly.

For the O'Reilly logo, maybe we could build on the pyramid idea and the
interchangable building blocks philosophy.

Or hey, this is Perl... anyone got any Tolkien references? Forging the
rings, Sauron and the Mount of Doom.

Garrett


> -----Original Message-----
> From: Andy Duncan [mailto:and...@ya...]
> Sent: Thursday, April 20, 2000 9:43 AM
> To: Hugo L. Casanova
> Cc: perldb-dev
> Subject: Re: [pdb-dev]Update on Camel Logo Use, Looking Good, Slogan
> Needed
> 
> 
> Hi Hugo,
> 
> > BTW I'm completely fanatic, I worked yesterday on a
> > logo for Anubis.
> > http://www.colba.net/~casanova/perldb/anubis.html 
> 
> Good shot, Sir! Looks fantastic :-)
> 
> I was going to mess about with a British Museum guidebook, a scanner,
> and the Gimp.  But what you've done's better than anything this
> would've resulted in.  Look out for Anubis-0.02, at a website near
> you real soon.  If it's Ok with you, it may come complete with a
> stylish logo you may recognise.
> 
> Rgds,
> AndyD
> 
> =====
> Pyramid Power
> => http://www.perldb.com
> 
> __________________________________________________
> Do You Yahoo!?
> Send online invitations with Yahoo! Invites.
> http://invites.yahoo.com
> 
> _______________________________________________
> Perldb-developers mailing list
> Per...@li...
> http://lists.sourceforge.net/mailman/listinfo/perldb-developers
>