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

[Sander Vesik <Sander Vesik ireland sun com>]

On Thu, 8 Feb 2001, Tom Cooper wrote:

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

[snip]

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

Whatever it is, it had better not be hardwire to using this or that
database.

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

That's an understatement 8-) 

Esp if you are looking from the p[oint of view of 'ooh, we can get client
side nice API/libs we only need to make a skin-deep wraper around'. 

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

As opposed to not tieing it to specific backends - but to protocols
instead and not ever having to worry? Just plug in another server and it
takes advantage of whatever this newer one supports.

> 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

imap and several other prototcols starting in i

> 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 do think seeing beyond just server - anbd looking at it as a
multi-server / multi-client / total interoperability thing would be
advantageous.

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

Hopefully we will have a list + website for all this by monday. 

IMHO, OGS 0.1 might consist of:
        * draft Level1 requirements doc
        * draft Level1 client side API doc [1]
        * any amount of existing source code towards these goals

Level1 - essentials
Level2 - stuff above level1 like replication, etc.

[1] Is it just me or does anybody else think that your desktop, your
browser and your office app (like say when doing mail merge or
whatever) should all talk the same api so it all actually works?

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

        Sander

One day a tortoise will learn to fly
        -- Terry Pratchett, 'Small Gods'