phpsqliteadmin-devel

[Phpsqliteadmin-devel] proposed class conversion

[Steve D. <sd...@wo...>]

Ok guys,

I've been spouting this dream of mine to use PEAR's native DB class as 
the backend API for connecting to the SQLite database, and here's how I 
think it can be done.

There's two reasons I want to use the DB class though -- one, it's 
installed with almost every php installation and it's very nice class 
(well documented too), and two, I'm already really familiar with it. :)

Anyway, this email is my proposal on ditching the old class, and 
integrating the parts that PEAR's doesnt support into PSA, and how it 
can be done.

http://sdibb.frogcircus.org/psa/psa_class_conversion.html

I put together a quick spreadsheet that has four columns:

SPLSQLite - has the functions of the old class you guys were using, and 
as nice as I think it is, I have no problems about abandoning it since 
DB.php already supports half the functions (as you'll see), and the 
other half can be put into the PSA class.

DB - If there's an entry in the column, then that value can replace that 
function of the old class.  In almost every case it's probably going to 
take a bit of manipulation and code cleanup to use DB instead.

PSA - The new class I already started working on, which will pick up any 
slack that DB can't handle, and at the same time pick up any functions 
that psa is using right now and integrate them in as well.  The PSA 
class of course won't be limited to just that stuff, but that will be 
some if of its main functions.

PHP - The actual php functions that the PSA class would use.

What do you guys think?  I hope my little spreadsheet makes some sense. :)

I can go ahead and start on the class conversion, but I just wanted to 
make sure we're all on the same page, and you guys don't think it's a 
bad idea using PEAR instead or anything.

Steve

Re: [Phpsqliteadmin-devel] proposed class conversion

[Yves G. <yg...@mi...>]

On Friday 12 November 2004 03:45, Steve Dibb wrote:
> Ok guys,
>
> I've been spouting this dream of mine to use PEAR's native DB class
> as the backend API for connecting to the SQLite database, and here's
> how I think it can be done.
>
> There's two reasons I want to use the DB class though -- one, it's
> installed with almost every php installation and it's very nice class
> (well documented too), and two, I'm already really familiar with it.
> :)
>
> Anyway, this email is my proposal on ditching the old class, and
> integrating the parts that PEAR's doesnt support into PSA, and how it
> can be done.
>
> http://sdibb.frogcircus.org/psa/psa_class_conversion.html
>
> I put together a quick spreadsheet that has four columns:
>
> SPLSQLite - has the functions of the old class you guys were using,
> and as nice as I think it is, I have no problems about abandoning it
> since DB.php already supports half the functions (as you'll see), and
> the other half can be put into the PSA class.
>
> DB - If there's an entry in the column, then that value can replace
> that function of the old class.  In almost every case it's probably
> going to take a bit of manipulation and code cleanup to use DB
> instead.
>
> PSA - The new class I already started working on, which will pick up
> any slack that DB can't handle, and at the same time pick up any
> functions that psa is using right now and integrate them in as well. 
> The PSA class of course won't be limited to just that stuff, but that
> will be some if of its main functions.
>
> PHP - The actual php functions that the PSA class would use.
>
> What do you guys think?  I hope my little spreadsheet makes some
> sense. :)

After reading this I for myself would probably like using the pear 
class, but I never tried pear before I must admit.

What I like about is that it's a maintained class, and the one we use 
right now is unmaintained by the original author.

What I don't like is the work that would have to be done to go from the 
spsqlite to the pear/psa classes.
Steve, would you volunteer doing it?
Right now we have a simple (but working!) phpsla in cvs, and it should 
stay like that... ;-)

If we do it, we must ship all the necessary files with phpsla, because, 
as Felipe pointed out, right now phpsla works right out of the box, and 
that should not change.
Not everybody (including me) has pear installed, and by shipping it we 
would also avoid any kind of version-problems.

Btw, is there no license problem shipping (unmodified) php-licsensed 
files within gpl app?
http://pear.php.net/manual/en/faq.licenses.php

cu,
Yves

p.s.
After we will all be on the same page, IMO Steve should get cvs access 
to allow him easy coding.
However I would like ot request that important or bigger changes, 
whoever wants to do them, should be discussed on this list.

> I can go ahead and start on the class conversion, but I just wanted
> to make sure we're all on the same page, and you guys don't think
> it's a bad idea using PEAR instead or anything.
>
> Steve
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Phpsqliteadmin-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpsqliteadmin-devel

-- 
Linux 2.6.9 #1 Mon Nov 1 12:01:23 CET 2004 i686
 10:25:26 up 12:33,  1 user,  load average: 0.75, 0.57, 0.57