Re: [phplib] phplib - what is the point? From: Björn Schotte (bjoern <email protected>)
Date: 07/22/01

* nathan r. hruby wrote:
> user of PHPLib templates will just need to go and edit their code which

No. At least if this user will start a new project, he won't
choose template.inc from the PHPLIB repository; instead, he'll
choose HTML/Template.php (or whereever it will be committed in)
and forget about PHPLIB.

> [...] You are promoting a fork,

Yep. Sometimes Kris' sentence "break things as early as you
can do" makes sense.

> Why? Are you single-handedly going to port all of PHPLib to PEAR?

No. I'm hoping that people will begin to convert the necessary
classes to PEAR. First step in my eyes was template.inc because
it was the easiest to convert. Next step could be OOHForms (although
we all wait for Ulf's XMLForms) and one of the big steps will
be Auth.

> Are you going to endure the roasting pear-dev will give you?

Nobody can roast me. At least not in real life. So I don't
care if Person XYZ as a member of PEAR-DEV roasts me or
not. Mailing lists contain much blabla - people tend not
to be like that in real life than they are in mailing lists.

> Are you just bent on forking PHPLib?

No. I'm bent on pushing PEAR as the future of PHP
components. As I see some PHPLIB classes as "components"
(Template, OOHForms, Auth, DB), I'll push them into
PEAR - at least I'll do something, not only saying words
and I hope that people will attend to convert classes
to PEAR.

If that will have been happened in some weeks/months,
I'll revise my training slides and forget about PHPLIB -
i.e. I'll train on PEAR components, unsubscribe from this
list and so on.

The only reasons that I'm using PHPLIB and that I'm
promoting it in big companies are the following classes:
Sessions, Auth, DB, Template, OOHForms. If those classes
can be merged to PEAR (could be easily done for Template
and OOHForms, for Auth/Session + local.inc there we should
plan how to convert them easily with breaking only small
pieces of the current API)
 
> and tehrefore nothing better to do than argue about what they
> *personally* feel is "The Right Thing For PEAR."

If you don't feel that it is the right thing for PEAR,
then go on and convince them about what is right. I have
clear visions what PEAR should be and I'll actively do
the work to implement my visions. (Personally, I hate
addFooBla() for function calls and so on, but if the
majority wants to have it: ok.)
 
> breaking the PHPLib API as you go.

Yep. Those things I'm converting to PEAR is not for
old/existing projects you might have - for existing
projects (which are working) there's no need to change
anything (i.e. I have been working with template.inc
from V7.2c for many projects now - for future projects
I'll use the PEAR version of it if it will be integrated
into PEAR).

> Greater control, higer visability, easier collaboration, standard set of
> tools, some one else admins everything.

And what about the *real* needs? (Fixing code, fixing
CVS admin's behaviour (i.e. social engineering) that
everyone can submit code and so on ...)

Moving to SF is only a waste of time and, in my eyes,
it pretends that the project lives. 

-- 
PHP Schulungen und                        | International PHP Conference
Schulungsmaterial:                        |             05. - 07.11.2001
http://thinkphp.de/                       |      Astron Hotel, Frankfurt
http://rent-a-phpwizard.de/schulungen.php |  http://www.php-kongress.de/

-- 
Abbestellen mit Mail an:   phplib-unsubscribe <email protected>
Kommandoliste mit Mail an: phplib-help <email protected>