vLIB as part of PEAR???

[releasedj]

Hello everyone,

Recently here on the forum, RNilsson asked the question "Have you considered entering the vLIB package into PEAR?"!

My response was that I have been considering this for short time (since the release of PHP 4.3.0), however I have a couple of issues regarding introducing vLIB into PEAR.. these issues are briefly discussed in the forum topic
*CVB: Hyperlink deleted*

There are pros and cons to this subject and I would really appreciate any comments on the subject.

Please voice your opinions as you please, whther youre for, against, dont care.. whatever!


Kind regards,

Kelvin

[paulfontfreide]

I don't understant the problem

[ClausVB]

I voted "No". But I am only 53% for "No". 47% think "Yes". :-)

It would totally be cool to have it integrated into PEAR so some of the best template classes would be availible to a larger scale of users.

I voted "No" because the have a template class

HTML_Template_IT

and imho we will have the "Fight the new one" people.

I think being on top of hotscripts and having the best documentation on a template class is enough.

Perhaps I would do the following, if Kelvin wants to integrate it:

Make two versions, but the PEAR version will only be created once or every time we have major changes like 2.x to 3.x or 4.x.

Just my 2 cents.

[RNilsson]

I voted Yes, some 60/40 mixture as i know there will be some work to make it fit into the parameters of PEAR.

For myself, i usually stick with one or a few "packages" of scripts i use, and i primarily use those that are from the same author (as it's most likely to function best together with eachother)

One thing that PEAR is missing, is a good Time/Date tool ( http://pear.php.net/packages.php?catpid=8&...e=Date+and+Time ) As it already have 4 Templates ( http://pear.php.net/packages.php?catpid=10&catname;=HTML  - Item 8-11 ) already, but one advantage of several scripts from the same author, is they may share the same basic configurationfile for "global" settings.

If there's two branches, they would require about the same release/update frequency otherwise one branch would tende to get left behind for different periods, as well as it's easy to miss updating both branches if the syntax differ alot.

If i would to choose, i'd port the entire vLIB to PEAR, but, i would add a wrapperclass that allows the current users of vLIB to call the functions using the same name as they have now, and when the users upgrade their code, templates, systems and scripts to a new major overhoul etc, a rekomendation could be made to migrate to the PEAR-style calling of the functions so the "wrapper" could be phased out in the future.

Anyhow, i think it's good to have the discussion open now...

*Addning another 2cents...

EDIT::
But to consider, PEAR wouldn't get shipped with the windows-version of PHP until PHP v4.3.1, and i'm not entierly sure everything in PEAR is installed by default (i'm still investigating and havent had time to upgrade my experiment-server yet) so any known input of how PEAR actually performes would also be important for the discussion.
/EDIT

..R

[releasedj]

I don't understant the problem

The problem with moving vLIB into PEAR, is that we would have to rename the base classes. Also, vLIB would be dependant on PEAR for error handling, so PEAR would have to be installed!

Kelvin

[releasedj]

Yesterday I spoke to some developers on the PEAR mailing list, and they told me that a library as such can not be submitted to PEAR. You must submit each class as a seperate entity, non-related. This means that there's no real way to handle a config file in the same way vLIB does.

With all this, I believe that it would be too hard to maintain seperate branches of vLIB.

I am following up however on a developer who told me that I can distribute vLIB using the PEAR installer without intergrating it into PEAR. I am waiting on some replies to verify what he meant exactly!


Regards,

Kelvin