[Phpgroupware-developers] Re: Serious PHPGroupware

[Dan Kuykendall]

This email was sent to me privately, but Im in a fiesty mood, so Im 
replying so that everyone can see and join the discussion if they want.

Grant Bowman wrote:
> Hi Dan,
>
> When are you going to decide to either get serious about PHPGroupware or
> hand it off? 

HAHAHA. I am not able to run phpGW full time, as its a free project and 
I have to pay the bills. I do take the project seriously and even have 
clients who pay me to help support them with their phpGW problems. But 
this is not something that I am able to do full time because there is 
not enough business out there for me yet. So I have a (more than) full 
time job, two kids and a marriage which all consume most of my time.
I put in as much time as I can into phpGW.

As far as handing it off, who has even shown a tiny bit of the 
leadership to take over the project? If I saw someone who wanted and 
showed that they could run it better and put more energy into the 
project, then the rest of the developers would naturally follow behind 
this person. I do not "own" the project, I am just do what I can to help 
run the project to the best of my abilities in the time I can squeeze 
out of the rest of my responsibilities.

Dont forget that a year ago it became clear that my new job was not 
going to allow me as much time for the project, so I stopped being the 
single "leader" of the project and instead we switched to a coreteam of 
five that were the "leadership team". Even then things havent picked up 
because everyones time tends to get cut into by other responsibilities.

> I don't intend this to be inflamatory, 

Yeah right, you intend it to be, in at least to get my attention.

> just to understand
> where the project is going and in what time frame.  It's a great project
> with alot of potential that I feel is stifled in a pre-1.0 state for
> some unknown set of reasons.

I agree that this is a great project and this pre-1.0 crap needs to end. 
I have made it known several times over the last two months that I 
intend that the next release be 1.0. Here is an email I sent out a few 
weeks ago. I have more to follow up on this and will send out more about 
this later.

-------- Original Message --------
Subject: [Phpgroupware-developers] My goals for phpGW's future
Date: Fri, 23 Aug 2002 19:34:40 -0700
From: Dan Kuykendall <address@hidden>
Reply-To: address@hidden
To: address@hidden

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