Re: [Phpgroupware-developers] My goals for phpGW's future

[Oliver Günther]

First: Good Morning from Germany to all and welcome back.

Now let's start. I'm new at this project. At the moment my company is running 
twig (twig.screwdriver.net).
Cause of the limitations of this project (no Javascript, fully structured), I'm 
on the way to change to 
phpgroupware. I the first stage (this is now), I'm implementing some 
requirements, that are needed here.
At the moment I write an patch, that will make it possible to create 
homedirectorys for new LDAP-Users.
(will be here today or tomorrow )
This about me, now to your "goals".

1. PHP3 support removed. 
Sounds good. Here I'm on your side. 

2. change from classes to services
Well let's see this from another point. phpGroupWare is as far from being 
objectoriented as the world from being 
in peace.
At the moment it looks like objectstructured.
A small example(phpgw 0.9.14RC4): class accounts of the phpgwapi: 
        a. this class extends a class accounts_ which is in 2 files including 
the desiered one with an if over a 
GLOBAL value.
        b. in befor this class there is a hole !GLOBAL! array set.
        c. method id2name can be extracted. If you remove it from the class an 
use the GLOBAL values about the 
database it works
           fine.
This is only a small example how far phpgroupware is frome being 
objectoriented. 
Now you sugesst to go one step ahead by changing to something called services, 
done by your ExecMethod.
In all code I read about ExecMethod yout forgot one esention point about OOP. 
You can only create
one object from each class with your function. Well, simple question: Why shoud 
I write class then I only can 
create one instance.
So my opinion is to reform, rebuild, redesign a hole part of the actual api 
into a real OOP-Style and then think
what make sense to be done over "service-calls"
Here is the first point to separate working code( database calls, 
authentication ) and GUI ( Graphical output).

Maybe you should describe more about what you mean with services. 

3. Make all apps to work with or/and as XML-RPC calls.
Here you should discribe more what you intent to do (or wish everyone should 
do).
I only can think about a RPC calls to the database services. I don't know what 
you want to do the apps especially
if you want an OOP design. 

4. Offline mode and Palmsync ...
Never though about this .. be my guest :-)

5.documentation.
Now here comes something, you missed out in your post.
5a. headerdoc 
The first thing: I don't like this.
headerdoc (as far as I know) can not document uncommented functions, needs tags 
like @function @class e.t.c 
and has no possiblety to show an class inherit tree. 
Here we should switch to a more phplike docsystem (phpdoc e.t.c.www.phpdoc.de, 
www.phpdoc.org) or my favorite 
"doxygen"
(www.doxygen.org)
5b. There is also more developer doc needet. (@ the moment there is only some 
small information how to add an 
app, and the 
GLOBAL array, which also is the opposite of writing OOP-Code)
Also the roadmap on the homepage is lost in 0.9.13 :-)

So please don't take this personal , think about it, and help all developers to 
make a clean path.

olli


Dan Kuykendall <address@hidden> wrote:

> I want to start of by making it clear that this only represents my 
> opinions and is not a dictate of how the project will move. I have my 
> influence and such on the direction of the project, but since this is a 
> Free Software project I am fully aware that everyone involved in 
> developing phpGW has a voice and can impact the direction of the project 
> greatly.
> 
> I have spent the last year or so mostly away from the phpGW code. I have 
> kept an eye on how things have progressed but havent really written 
> alot. The time I have spent on phpGW has been in trying to understand 
> the direction the industry is taking. I have written dozens of chunks of 
>   experimental code to find ways to dramaticly improve phpGW. I have 
> searched for various technologies and standards that could help phpGW 
> move into other areas and not just be a web app.
> 
> PHP3 support: My plan is to have 0.9.14 (planned for release this 
> weekend) be the last version of phpGW that will be compatible with PHP3. 
> The FSF is finally going to declare PHP 4.1.2 and up as Free Software 
> and that allows us as a GNU Project to finally be able to abandon PHP3 
> support. PHP4 has sooooo many benefits in how it handles OOP and XML 
> that we will be able to really improve the performance and features of 
> phpGW dramticly.
> 
> Web Services: This is an area that can offer phpGW the chance to really 
> break out and broaden the usefulness of the code. We have tons of logic 
> in phpGW and we need to just make it more avaible outside of the phpGW 
> web interface. We have started with some decent XML-RPC support which is 
> a great start, but much needs to be re-worked in phpGW for it to really 
> become useful.
> I have stopped thinking of the various parts of our code as "classes" 
> and started to think of them as "services". For example, instead of our 
> accounts "classes" I think of them as accounts "services". To bring this 
> to a more functional use I have been working on a method for all 
> "services" to be registered in phpGW and then have a single way to 
> interact with "services". This is done via my new ExecMethod() function. 
>    First the services all get registered. The registration indicates 
> what protocol is to be used, and the location/url. If the service is a 
> PHP class file like we have now (I consider this as protocol "PHP"), 
> then ExecMethod() will make sure it gets include()'d and will execute 
> the requested function. In the past ExecMethod() has been considered too 
> slow because it used exec() to execute the function and exec() tends to 
> be a drag on performance. PHP4 has a perfect solution in 
> call_user_func_array() and call_user_func(). These function will do 
> exactly what we need. The real benefit of the new ExecMethod() is that 
> it will have web services clients for it to use. So if a service is 
> registered with protocol XMLRPC and it has the URL, then it would be 
> possible to have all the accounts functions on some remote web services 
> server. Of course this wont always work transparently because the web 
> services server might not have the functions and return format we 
> expect, so wrappers can be written. I have considered just using 
> wrappers, and in the end that may be what happends, but I think the new 
> ExecMethod() may become more flexible because it will more easily allow 
> for having the phpGW server broken up for load balancing and such.
> 
> XML: I have been fully xml-ized over the last year. I have written a 
> function that will convert any param into useful XML. For some reason 
> none of the array2xml type functions I could find would give me usable 
> XML, so I wrote my own that is fantastic if I can say so myself :-p
> I wrote it for the new templates class I wrote. XML will be be 
> everywhere in phpGW, from the templates system to the web services 
> interfaces and may places in between.
> 
> Templates/XSLT: I wrote a new templates class that has some minor 
> similarities to the current PHPLIB ones we use today, but the new 
> templates class uses XSLT templates which give the templates the work of 
> building the HTML interface. XSLT can essentially take over the entire 
> UI layer of phpGW. Its a forward-compatible technology and offers 
> tremendous flexibility in what the template designer wants to do with 
> the data.  Basicly the api and apps just feed the templates class its 
> variables. Generally this would be arrays of the information reguested. 
> The templates class will then convert all of this data into an XML doc. 
> It also takes the list of XSL files needed for this and merges them 
> together. Then it passes this off to PHP's XSLT engine to process and 
> generate HTML.
> Mozilla 1.0 and IE6 have XSLT engines built into them but mozilla's is 
> very instable so its not good to be used. But as time goes on it will be 
> fixed. What this allows us to do is to simply pass the browser the raw 
> xml data doc and tell it how to get the XSL doc from phpGW and then the 
> browser is responsible for processing that into HTML for the user. This 
> can take a load off the server at that point.
> 
> 1.0: I want 0.9.14 to not only be the last of the PHP3 compatible 
> versions, but I also want it to be the last of the "perpetual beta" 
> versions. I want to get the API and core apps to be fully using the new 
> templates system, provide all of its public functions out over XMLRPC 
> and SOAP and work well and then make it 1.0
> 
> Offline mode and palm sync: This is an issue that plauges me, haunts my 
> nightmares, etc etc... The palm sync thing appears to be on its way to 
> being solved. The Axisgroupware guys have gotten it to work. Right now 
> its some perl code that writes directly to the database, but that can be 
> ported to talk over xmlrpc soon enough. Offline mode is another story 
> and not one easily solved. I am still searching for a solution, but I 
> think its going to require putting some created/last_modified fields in 
> each of the tables for the apps so that users can basicly copy out all 
> of their data to a local database of some sort (maybe even xml files). 
> The local data source can possibly handle some changes to the data, and 
> then be synced back up by compairing the time stamps involved. This is 
> going to be important to at least make the table changes now, so that 
> post 1.0 release the pieces will be in place for it to be solved.
> 
> There is lots of other little things, like using 
> register_shutdown_function() from the API startup process instead of 
> requiring apps to have
> $GLOBALS['phpgw']->common->phpgw_footer();
> as their last line in the files. Stupid things like this can make it 
> easier for app developers to focus on their apps and have a super easy 
> way to plugin to phpGW.
> I am also going to make certain that I finish the few changes that are 
> needed so that apps can be easily turned into stand alone apps, but 
> simply including a few limited parts of the phpgwAPI into their app dir. 
> I think this will make many developers of robust PHP apps more 
> comfortable to port their apps to work within phpGW.
> 
> Soo much to do, but it can all be done if we want it so.
> 
> I look forward to comments, and suggestions. This is by no means a 
> complete list, but it covers the most important issues I can think of at 
> the moment.
> 
> Seek3r
> 
> 
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
> 
> 



--