Re: GNU GLUE?

[Dan Kuykendall]

> I think PHP Groupware and GNU GLUE are addressing two different user
> classes at the moment and maybe they'll meet somewhere in the distant
> future.

Could be the case

> It is not (yet)
> possible to have multiple synchronized local servers (imagine a user in
> India trying to access the companies groupware server in Europe with a network
> latency of around 0.8s - this is an existing setup!), it is not possible
> (yet) to use PHP Groupware in an offline mode (imagine a Laptop user working
> in a train and having no permanent Internet access due to financial and
> technical reasons).

This is the reason we split out the sessions class to be able to use a
seperate db server. The sessions table would be best servered on a
single server, because replication woudl be a nightmare with this fast
moving table, but all the other tables can be done with any db
replication system. We have not fully tested this out, but the code is
in place to support having the system mirrored.

> This is where the GNU GLUE concept comes in handy: Imagine a "totally"
> distributed Groupware concept where multiple servers share the same
> replicated data and applications - one of the servers may even be located
> on your personal laptop and therefore work in offline mode. Well, there
> are lots of synchronisation issues now, but the two problems mentioned
> above are solved. Actually once the basic application framework is built
> it should be as easy to write applications for GNU GLUE than for PHP
> Groupware - maybe :-)

We are working on our SyncML support for Palm Pilots and such. But
having a native client is very handy for laptop users. This is one of
the reasons we are in the process of drafting our an XML-RPC/SOAP
interface to phpGW. It will support syncing and we have some interested
developers who are going to try writing a GTK client for it as soon as
its in place.

> In the distant future someone might add multi-server-synchronisation
> and offline support to PHP Groupware and in the distant future someone
> might write a version of GNU GLUE accessible via the Web (the latter
> should not be too much work if GNU GLUE's design allows this from the
> very start).

Both would be great.

My big hope is that GLUE starts off by writing a iTIP daemon
(http://www.imc.org/pdi/), then join that together with an IMAP daemon
and maybe some contacts records daemon that supports vCard. Of course
there would be some master daemon involved to maintain user accounts and
such, but putting the back end together will then allow a mad rush of
client side development by interested parties. I know I for one would
immediately start working on creating a calendar class for phpGW that
would use the iTIP service instead of our SQL table. it would be an
option for users, but in general this to me is where the free softwqare
community is lacking.
Dont worry about the front end, every damn open source developer in the
world will jump in and fill that hole. We need some kick ass developers
to commit to building the backend for us all to use.

> I'm just hoping GNU GLUE is not going to be too much like Lotus Notes
> (where the local "fat" Notes client is just much too fat and the
> existing web gateway "Domino"(?) is way from offering the same functionality
> as the "fat" client).

As stated above, I REALLY suggest that you drop the client side plans
for now and focus on the backend services. Doing this thru open
standards like IMAP and iTIP would allow for other developers to start
on the client side code. The clients that will appear will be web based
and native code, just like you see with IMAP clients.

> And some criticism: As long as GNU GLUE is an abstract thing with no
> code at all it will be hard to find someone who will contribute. Maybe
> the GNU GLUE should consider the "start small" concept? Maybe not ...

Maybe the small start could be to merge a account management daemon with
an IMAP daemon, then start work on writing an iTIP daemon that woudl
work in tandem with the first two.

When I started with phpGW, I had really wished that such a backend was
availible in the free software world. I knew I wasnt a talented enough
programmer to do it, but I knew someone else could, and I would support
them as much as possible. Im a better programmer now, but dont know C
well enough to take on a task like I mentioned.

Thats my 2 cents

Seek3r