Continued phplib and pear merger thoughts

Ok.. 

I guess I'm the one who opened up the can of worms again so I should chime
in here :)  My intesion was not to start a war over DB classes or start
throwing around insults about the phplib'ers nor the PEAR-ites, it was
simply to check to see the status so I can plan accordingly for upcoming
projects.

Originally, when Kristian announced that phpLib was (wanting) to be merged
into PEAR, upon my joing the php-pear list there were two general
conceptions about the idea:
1) That's great!
2) PEAR should not be a repoistory for application framework such as phplib
[ The whole dabase class mess was mentioned but never a central issue, if I
remember correctly.. simply something that needed to be delt with. ]

When I mentioned in my orignal post over the weekend on the phplib list that
some PEAR folks were aginst merging phpLib into PEAR, number 2 above was
what I refering to.  I think by the end of the conversation that foloowed
the original merger announcement it was generally throught that the merger
would happen and a few folks were a bit pissed about it (allowing an app
framework  into PEAR.. Chuck I still fail to see how having PEAR/App/Phplib
is forcing bloatware on people, It they want to use it's there, but not
incuded as a constant...?  Why *can't* PEAR have a toplevel App Tree?).  I
happen to agree with number 1 more...  I don't (and didn't) understand why
app frameworks couldn't be part of PEAR.  [ I think Rasmus agreed that
frameworks should be allowed in.. in his words "a kitchen sink repoistory."]

In the past discussion the idea was to put phplib into its own branch
seperate from the rest of the PEAR Classes (ie: PEAR/phplib) and either port
phplib to use PEAR/DB and friends (and provide a backwards comaptible
wrapper class to access PEAR/DB with phplib style access) or import the
phplib DB_* classes as is (with fixes for PEAR naming conventions) as a
stopgap measure until PEAR/DB can be fixed to be faster, I for one also like
the access methods of phplib better that PEAR/DB, though that's just my
personal preferance and what I started out using.

I'm all for the second method.  I know that Kristian and Ulf want / need
help with phplib and that both the phplib and PEAR communities could benifit
from each others exsistance.  I see no reson why PEAR *can't* have two
seperate DB classes (for a short time or a long time).  Neither requires the
other nor interferes with the other.  This was my sentiment a moth ago and
still is.  I realize that the PEAR naming and file layout need to be
followed, which is fine.  this will probably break some stuff, and yes that
will require a compat wrapper script.  Again, so swhat, this only effects
old phplib apps that ahve yet to be rewritten.  It's not a long term
solution (though again.. I still like phplib subclassing)

As far as people helping out phplib and PEAR.  I'd love to if I had the
time, if I did I would of picked up the project at it's inception a month
ago, but I don't, but I'm not bitching either.  I'm always happy to try new
stuff out send in fixes when I can but that's not what this merger needs
right now, it needs a friggin' leader so help deal with the "Do we port to
PEAR/DB or keep the DB_*.inc classes"  That isn't something that just anyone
in the phplib devloper community can just pick up and do.  This is where I
look to Ulf and Kristian, phplib is thir brainchild, they know how it works
the best, they are in the best postion to pick it apart and tell/show others
how to best go about to PEARifiy the code.

Ulf, I know you've gotten a bit upset about how it seems that people are
just complaining about this whole ordeal.. We aren't but no one knows better
than you and Krisitan how to answer a lot of the questions that are flying
around here, and so far thay haven't been answered.  This can't be a "Let's
vote on it and discass things" migration, you need to make an active choice
to break stuff (and then fix it again :)  *we* can't so that, unless you're
completely abandoning phplib altogether and leaving it for the wolves.

Timings, compexity, simplicity and extendability aside, this is a discussion
of two very different ways of dealing with php.  The code and technology can
be sorted out, but the overlying design and coding philosophy (at least as
it seems now) can't be.

-n

-- 
......
nathan hruby - [email protected]
computer support specialist
department of drama and theatre
http://www.drama.uga.edu/
......