phpGW and DotGNU: (was: [DotGNU]SourceForge drifting)

[Dan Kuykendall (Seek3r)]

"Gopal.V" wrote:
> 
> Hi,
> > I have looked at phpgroupware, and think it has a very excellant set of
> > ideas in it.  Where/how it fits/relates to DotGNU as currently engaged, I
> > am not precisely certain, but I would be happy to talk about this further.
> > I understand that php may again become free software, and if so, this is a
> > good thing.
> >
> > David
>         If ZEND becomes GPL'd , we have a highly optimized php engine. In the 
> end
> I think it will ( look at qt :).

Its probably less likely that it will be GPL'd, but from all accounts it
should be switching to a BSD style license, which should be ok because
at least we will have a clear ability to fork the code if nessesary.

>         PHP is a core language for dynamic data generation for the web. If
> PhpGroupWare has a SOAP/XMLRPC interface, it could well be the first
> real webservice we could plug dotGNU into. Moreover since it supports
> PHP3, we can use it on our servers. Unlike the jabber servers, we have
> no licensing problems. The XMLRPC interface ( I am told it works), could
> be used to run dynamic apps. I think there are a few news ticker programs
> that use PHP to get data dynamically. But unlike these static format data
> acquisition, XML data is much more flexible. This may also be standardized
> eg a function to get the list of all webservices.

Yes, PHP is pretty great for generating html or xml files. Thats really
what its designed to do. Our xmlrpc interface *does* work and we already
have a limited client written in Klyix that is a very nice proof of
concept, as well as a good test bed. 

I do believe that phpGroupWare is the most complete webservice in the
Free Software community, at least the most complete I am aware of. 

>         After all this talking I am beginning to think implmentation side of
> the webservices.
> 
>         This combination of PHP for server-side, python for the UI , and 
> XMLRPC
> for communication would result in something far greater than Xforms.

I still think things like XForms will be important... and I wouldnt want
to tie DotGNU into any languages. 

> Imagine a standard set of GTK-widgets+GladeXML for all machines. Just download
> the .glade file ( automatically ), run using the python GladeXML ( we would
> need to do something to connect events , but since python __dict can be
> updated at runtime , we could use a remote function lookup and connect wrapped
> functions ) then communicate data from/to the PHP groupware for processing
> (may be implement a database query). Voila A live web app. This is not as
> easy as it sounds, 'cause security is a *BIG* issue for webapps. Like
> a webform, we may also be able to add a scripted data verifcation.

Yes, this would certainly work. The fact that this plan is tied to
having to use Glade would probably be an isue... but its certainly one
of the options.

>         Once I started thinking this, I came to a better idea, why use PHP for
> server ? . We could as well use GEAS ( Daniel are you listening ? ) for
> this purpose . But I will leave the decision to dotGNU.

My biggest goal is not to force anything to be done in PHP. I am working
hard to get a working implementation of a webservice for basic
account/preferences as well as standards for the standard groupware
applications. I consider phpGroupWare to be the best way to bring
working code to the public. Once its a little more compete and stable,
then a standard can be defined around it and a new server that follows
the standard can be written in any language. In this GEAS can very well
follow our standard and build the data store and business objects and
then work with any client that is written to talk to phpGroupWare. I
originally started this as the "Open Groupware Standards Project" and
because of some convincing from Bradly Kuhn I am renaming it the "Free
Groupware Standards". I think that my overlap with DotGNU is massive and
I want to work closer with you guys.

Some of my most important concerns is that we develop a standard way to
handle authentication (I know you guys are working on that), account
information, and preferences. 

Account information should be easy, because standards like an xml based
vCard combined with some of the LDAP style. Of course the one this that
needs to be figure out is handling auto account creation. For example,
if I setup things so that I am using some DotGNU version of Passport and
I create an account on there for my user and then I use GEAS for my
account and preferences data. I need GEAS to be able to see that the
user has authenticated against the trusted authentication service, and
then auto generate an account for that user and simply fill in some
default settings. We already do this in phpGroupWare and it will be
important in the web services environment to have some consistant way of
doing this.

Preferences shouldnt be that hard and we can used the xml-ized version
of ACAP as a good starting point.

It should be possible to have all 3 of these services running on
different hosts and with different software, as long as they all follow
some standards things should jive very well.

Anyways, I am rambling on and I have lots to say on several of these
topics... so I will start sending emails about each as time permits.

Dan Kuykendall