Difference between distributions of 3.2.0

the zip file download at tinybutstrong.com and the tar available from phpclasses.org are different in structure, filename (of the 2nd most important file, the php4 class file).

Even the actual name is different.

I have not diffed the individual files.

Which is the intended correct latest release?

I think that the archive/packing method should not require different naming and structure.  I think it should be easier for the last step of your build to just archive and compress the exact same tree. 

This would be so easy that you could add all the other methods that some ppl like, almost for free (bz2, arj, rar).  If this is properly automated, it can be easier, cheaper in labor and more reliable.

I think tbs is the best applet available - the name is exactly correct.  I update my clients to the lastest release  often and I want to be sure I have a good, reliable way of getting your best stable package.  I am hoping that the suggestions I have made would make your job easier as well as mine!

Hi Brandon,

Thanks for your remarks.

The TBS sources available at phpclasses.org are exactly the same as those provided at tinybutstrong.com
After you remark, I've go an check at phpclasses.org but it was the correct source. At PhpClasses, you save your source by copy/past by default. I thought maybe it had converted Unix line breaks into Windows line breaks ans so display a different total of bytes. I've reloaded the source by upload, but nothing has changed. I think all is correct.

In the new TBS package I've changed the file name "tbs_class.php" into "tbs_class_php4.php" because it seems that more and more developer are now under PHP5, so there is no more reasons to give the PHP 4 source as default.
I haven't changed the name at PhpClasses because it goes with the examples. Do you think I should make all clear by changing all example to use "tbs_class_php4.php" ?

> I think that the archive/packing method should
> not require different naming and structure.

I do agree but I must admit I haven't found a convenient way to package all in one yet.
As you are a real user of TBS packages, could you give other advices so I can make a nice and practical package ? The last package looks ok for me and I like its way to display things with simplicity.
(skrol29 at freesurf.fr)

> This would be so easy that you could add all the other methods that
> some ppl like, almost for free (bz2, arj, rar).  If this is properly
> automated, it can be easier, cheaper in labor and more reliable.

What is PPL ?

PPL = people  (sorry for AOLspeak :) )

I think the inside of the zip is better laid out although I might put plugins and examples up one level (no 'more' dir) and add a classes dir to put in tbs_class....php.  But this is opinion and different people will like different layouts.

I think the main point is to be very consistent so the name of the package is always the same (except to the part saying what is the archiver (zip, tgz, bz2 etc) AND unarchived tree is always the same as to directories and files.  The test is:  If I unarchive two different packages of 3.2.0, then diff should have no output at all.

Sometimes this means using something that is not the first choice because somebody (like maybe phpclasses.org?) has a convention that you must follow.  In this case it still may be true that consistent is best and we just use the most strict rules!

I do not see good consistency in phpclasses.org from one package to another.  I wish everybody would use a form of the general debian standard or some other that is consistent.

About making the examples use the name with '4' in it:  In the ideal case, all names should be clear and easy to tell.  But I think you may want to decide how to name everything in the future so that you do not need to change any names, no matter what the use of the name!

The php4/5/6 problem is a bad one for consistency!  The solution must mean the minimum work for you because users like me need you to be designing and coding, not doing library work (unless you really like it :) ). 

I use the classname without the number and then symlink or rename to make my code point to the right one.  Unless you do some very fancy thing, it is hard to make the 'require' or 'include' get the appropriate one. 

But I think it is ok for an app installer/maintainer to decide on the right release and use static techniques to control this.  As a system manager I do not want the executable to change automatically.  I must control when a new release is used!  I can tell you a very funny story about how a compiler upgrade stopped a very large financial compay's web site due to lack of such control.  It was not really that funny to the vice president who had to go to work as astreet sweeper :)
Regarding a packaging step - this seems like a nice trivial project for me.  I will start from the point where you have the tree of files for the package all ready and will have 2+x parameters:  the treeroot, the name of the package and the list of archive types to produce.  I assume you develop on XXnix, not Microsoft?  Bash is an acceptable language? I do not think a real make/build is necessary, unless you already use one :)

To post your release at phpclasses, you must copy and paste each file?  This is terrible - they should allow you to upload a package file, then urge you to use the structure that they want!

> I think the inside of the zip is better laid out although I might
> put plugins and examples up one level (no 'more' dir) and add
> a classes dir to put in tbs_class....php.  But this is opinion and
> different people will like different layouts.

It looks a good way. I'll ask to other developers what they think in order to propose a stable package draw that is ok for most of TBS users.

> The php4/5/6 problem is a bad one for consistency!  The solution
> must mean the minimum work for you because users like me need
> you to be designing and coding, not doing library work
> (unless you really like it :) ).

I agree. What about putting "tbs_class.php" in two different folders: php4 and php5 ?
But this won't be compatible with PhpClasses.org.

> To post your release at phpclasses, you must copy and paste each file?

Yes  :(

> they should allow you to upload a package file, then urge
> you to use the structure that they want!

The structure is always flat at PhpClasses.org :(
And admins of PhpClasses.org ask for a download & play example in order to make a review.

The renaming of the main class file was a surprise, but it made me think a little more about the packaging questions...

IMO the main class file name should always stay the same - for backward compatibility of user applications. In fact it should allow for unzip/tar directly into the users preferred directory, and _not_ rely on the user have to set/changing any path settings from previous installations.

It is usual for me at least to set classes in a path/location above the webserver root for security. Then application configuration files point to the TBS home. I would have to edit a lot of application files every time the file naming or structure changed.

If the default class eventually becomes the PHP5 version then include a PHP5 class that is named tbs_class.php and include other PHP-specific variations with related the suffix and let user rename for their server environment.

Also, the distro would be good if it were _flat_ including ALL class files and default plugins at the top level. The docos and examples could/should be in separate subdirs of course.

As so...
./tbs_class.php   (default: could be PHP4 or PHP5 specific)
./tbs_class_php5.php
./tbs_class_php4.php
./tbs_plugin_mmm.php
./tbs_plugin_nnn.php
./tbs_plugin_ooo.php
./docs/
./examples/
./extras/

My 2centimes (sp?)

Post script:

For consistency, the release packages for plugins from third parties should be recommended to have the _same_ package organization as the main TBS release package structure so that upgrades for those would be consistently the same.

Interesting.
Shouldn't plug-ins be placed in the extra ?
"tbs_class.php" will become a problem when it will turn from PHP4 to PHP5.

Previously I used /extras/ for things like db class (I use ezSQL), but now I place any db classes in top dir with the tbs_class.php -- again it make it more backward compatible without change application code.

This makes it easier for me to test beta version of TBS and ezSQL like this directory structure...
./tbs/               (production release classes)
./tbsbeta32rc2/     (TBS beta)
./tbsezsql203beta2/    (ezSQL beta)

Then I just use PHP's include path switching in the .htaccess file
include_path = ".:/user/home/public_html:/user/home/phpclasses/tbs"
# include_path = ".:/user/home/public_html:/user/home/phpclasses/tbsbeta32rc2"

This way I can easy switch back and forth between production and beta versions just changing _one_ line in .htaccess and change nothing in any application files.

As for PHP5 - though I am running PHP 4.4.4 on my local  dev server and my www servers - I already have started to use the PHP5 version of the tbs_class. But I do that by renaming tbs_class_php5.php to tbs_class.php -- it's easier to me.

My conflict is between a directory structure that is good for maintenance (several directories with names like plugins and contrib, which is good for maintenance and system management,

and

a flat directory which is good for coding, using a class_lib pointer, as many folks do  :)

I can get used to anything that is logical and consistent.  eliminating the language designation in the default main class name is a very good idea.

Hi,

I've taken your remarks in account for the new release TBS 3.3.0.
It has change once more from the previous package, but I think is is stable now.

I've seen several ways on the web to publish a couple of scripts to be run with PHP4 and PHP5. I've choose one. "tbs_class.php" is the default file name and is in PHP4. This is because it is still the more used version, and because it is compatible with PHP5.

And now PhpClasses can do subfolders.

Great!

Eventually you should be swept along to 5 but of maintaining and  increasing the user base is so important!

I think writing php4 code that works in php5 is a very valid compromise.