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

[Dan Kuykendall]

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