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

[Tom Cooper <tom_cooper bigfoot com>]

I've been lurking here for a while, and just couldn't hold back from
joining in the discussion.

My .02 follows

Dan Kuykendall wrote:
> Yes, most are all dead because they couldnt build a solid foundation to
> work from. Running the phpGroupWare project, along with being a
> GroupWise and then Exchange and now Notes admin has taught me a
> considerable amount about groupware systems. I feel like I can build a
> design with the help of a few others with experience writing and
> maintaing groupware systems. With this small group we can get something
> done faster and then can open up for public discussion/critisism.
I used to be an admin for this sort of thing.  I was at one time a
certified engineer and instructor for WP Office (when it was an email
product - before Novell bought it and turned it into GroupWise) so I
understand something about the architecture of a product like that.  I
was a Notes admin briefly, too, and managed to escape prior to having to
implement Exchange.  

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.

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

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.  

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!

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.

The primary consideration is determining the architecture and the engine
that will drive the technology.  

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?

Once we've defined the back end, it should be as simple as building a
wrapper around the technology that we select.  (I know that's a major
oversimplification.)  

Realistically, whatever engine is selected will determine the
architectural limits of the size of implementations.  Ideally we could
pick something that would scale at least to a mid-size business, and
while data storage capacities will increase dramatically as we move
forward, we need to consider user data sizes in excess of 2GB.  While
most users don't need that kind of capacity, many do.  

We've seen talk on the evo list about scalability issues between maildir
and mbox, and unless we account for that in terms of user data needs,
the open solution will have real scalability problems.

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.

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.  

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'm all for getting gung-ho and putting fingertips to the keyboard, but
> > it's wasted effort if you don't have a coherent concept.  I'm not
> > advocating committee paralysis, just some simple discussion over what
> > will / will not be addressed in the project and setting some priorities.
>
> I agree we need the concepts first, and I fully plan to work that way.
> but I dont plan to have every tiny function decided before I start
> hacking.
Plan the work, work the plan.

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.

The scope of features for version, say 0.1 will tell us when that engine
has everything that it needs, and the functional requirements define the
minimal quality requirements for those features - the features are done
when the quality requirements are met.

Thanks for letting me get this off my chest.

Regards,
Tom Cooper
-- 
Standard disclaimer applies:
This message represents the opinions of the
author, and not necessarily those of any 
organization to which he may be related.