Re: Applications in PEAR (or is Pear 1.4 going tochange things ?)

Martin Jansen wrote:

So IMHO applications if they are very focused in their usage and are developers tools rather than end user applications.

Can you give examples of applications that fit into this scheme?

I am pretty much with Scott on this one. He listed the following: PEAR Installer http://pear.php.net/package/PhpDocumentor http://pear.php.net/package/PEAR_PackageFileManager_GUI_Gtk http://pear.php.net/package/Gtk_VarDump http://pear.php.net/package/Gtk_MDB_Designer http://pear.php.net/package/PEAR_Frontend_Gtk *Note the following is more brainstorming and _the_ answer* Now Arnaud listed in his "bug report" that phpMyAdmin would not fall into the tools category. I do not agree quite as easily, though phpMyAdmin is an incredibly overdeveloped "application" in many ways, though probably 99% of the features can be argued in. For example we have MDB_Frontend in CVS (although it was never developed to any useable state). The idea would be to have a generic phpMyAdmin like "tool". Now when I talked about why not having applications in, the main reason was since we want to keep the scope manageable, by not allowing frameworks in which will inherited come with applications. So I think tools need to be very use specific. IMHO phpMyAdmin does not fit this category. This certainly is and will remain a grey area in my opinion as I do not know when something like MDB_Frontend would cross that line. So maybe MDB_Frontend does not fit afterall. I do not know if we can find a somewhat clear guideline on this, or if its has to be a case by case thing. Once the application needs some fancy plugin mechanism, complex authentication schemes etc its beyond our scope definately. However to me this sounds to me like we intentionally want these tools to remain overly simple internally even if they become more complex and would benefit from a more advanced internal structure. Like in MDB_Frontend you could have different modules for data management, schema diffing, schema exporting, database server management, user management etc. Also you may consider using LiveUser to handle premissions. So even if MDB_Frontend is proposed as only "data management" there is this tendency to tag on one feature after another. Should in this case it be forced to make these separate packages you will likely have some duplicate code between the multiple packages that a plugin architecture would work around. What I clearly dont think should be in PEAR is a forum, mailinglist, shop etc. regards, Lukas