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

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

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

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


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

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 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

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

Thanks for letting me get this off my chest.

Your welcome. ;-)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]