Re: [Evolution] CALL FOR SPONSORSHIP: The Open Group Ware Project
- From: Lloyd Llewellyn <subscr001 twilight-systems com>
- To: tom_cooper bigfoot com
- Cc: Evo-List <evolution ximian com>, OO-List <discuss openoffice org>, Glue-List <glue gnu org>
- Subject: Re: [Evolution] CALL FOR SPONSORSHIP: The Open Group Ware Project
- Date: 09 Feb 2001 23:03:45 -0500
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?
My original conception was to make the back end pluggable, given the S
on OGS. There should be a mapping layer between the goupware
application services in the middle and the back end storage. You should
be able to swap in DB's. If an organization already has Oracle running,
OGS should be able to store its data in Oracle.
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
Absolutely. We need to define the functions, define an architecture
they fit into, then address each function within that architecture. It
doesn't mean you have to have a complete blueprint before you start, but
you have to resolve interdependencies and make sure one module's
implementation doesn't conflict with another's (eventual)
implementation. By just jumping in you waste time and end up having to
either throw away code or force subsequent code to accommodate mistakes
made in the first round.
I'll start a thread called "What Is OGS?". It's time for us to start
sharing knowledge about the different parts of the elephant.
] [Thread Prev