Re: [Evolution] CALL FOR SPONSORSHIP: The Open Group Ware Project

[Dan Kuykendall <dan kuykendall org>]

> Today I'm an exchange user - and a fairly hefty one at that.  Exchange
> holds my corporate database - tasks, calendar and contacts as well as
> records my communications with others.  I depend greatly on this
> database.

How scary to depend on Exchange for your data. M$ was foolish to use a
jet db for such a massive application.

> The key concept is the storage engine driving the groupware server  -
> all of the messages and data need to be stored somewhere.

Exactly. This design should not in any way define how the data should be
stored. The data can be stored in any format, this OGS really will
define how teh server will give access to said data to the client.
For the phpGW implementation we use several schemes. We currently
default to using ANSI-SQL, but have objects to store account records in
LDAP, addressbook records in LDAP as well, authentication can take place
from SQL, LDAP, PAM, IMAP, NTDOM or whatever someone wants to write an
auth class for.
If some weirdo wanted to implement some components to store the data ni
XML files, they could do that. The implementation will be completely
seperated from the OGS definition.

> As I understand it, Microsoft is kicking themselves now for the
> Outlook/Exchange architecture - sync is a real hassle, and of course RPC
> over NetBIOS over TCP/IP is a lousy solution anyway.

Include the use of a JetDB for the exchange server.

> They are in the process of moving to a new infrastructure using http as
> the transport, XML as the data format, and relational DB technology on
> the client.  Their ost and pst solutions are terrible at handling large
> qualtities of data!

This is because they are now moving to make use of SOAP. The XML-RPC
solution (close cousin to SOAP) which I am planning to use, starts us
off in the right direction. I also plan to use a possibly extended
version of SyncML's design for the data sync that must take place and
this will also include supporting hand held devices.

> If we can implement something similar to what MS is starting to build
> today - starting with the back end and progressing to having a service
> on the client providing sync and archive services, we'll have something
> worthy of competing with Domino and Exchange.

I think we will be able to beat them at this game, because we are open.
We are not limited on the various client implementations and server
implementations that can take place. If you use Exchange Server, you
must basicly use Outlook. If you use Notes server, your stuck with Notes
client. When this OGS is in place, you could use "The phpGroupWare OGS
Server" as your server and Evolution or OpenOffice as your client. At
some point someone will build a better/faster OGS server, and the
clients will be able to simply point to it without any change in their
code.

> I'm no DB geek by any definition, but has anyone thinking about this
> considered what/how the database ought to work?  Is it possible to
> implement a solution built on top of MySQL or Postgres, or something
> else that might scale well?

Again this points to the reason for data storage to be seperated from
the main protocol. In the initial implementation that I work on
(phpGW's) it will basicly all be done with ANSI-SQL code with DB
wrappers for most sql servers.

> Additionally I believe strongly that we should not re-invent the wheel
> on this one.  The good news for us is that the base protocols are
> already defined, and the problem is one of data organization rather than
> message flow.  We can leverage open standards like http, ssl, xml in the
> process, and leverage open source engines to help read and write the
> data.

Agreed

> There are some things for which there are not open protocols - for
> example, tasks (AFAIK) - but that need not slow down the vision or early
> versions.

Some of the iCalendar stuff covers todo list data.

> What's it going to take to get others of you involved in this?  To add
> some detail to the picture of a truly open groupware server platform?
> Surely you have needs that aren't met by existing products....

I am working on putting up the www.ogsproject.org website and will be
putting as much information on there as possible. In a short time I will
send a press release out to the major news websites and see how this
goes. I do have a major chore in running the phpGroupWare project and my
own business so this is not going to be up immediately. Since phpGW has
been moving in this direction anyways, I will be running the two
projects as closely as I can so that neither gets ignored. Hopefully
others will jump in with me and make some commitments to getting the
documentation and design work done.

> Let's pick an attainable scope of features, determine minimum functional
> requirements for those features, and then get started.  We need not
> define a huge feature set initially, but we need to understand the
> architectural consequenses of decisions made when implementing those
> features.

Agreed. And just about everything needs to be done in well definable
layers, so that any layer can be replaced by better/specialized
replacements.

> Thanks for letting me get this off my chest.

Your welcome. ;-)