[GNUccess-design] After the "meeting"

[Bartek W. <ba...@re...>]

Hello !

So we are after our first "meeting" :)

It wasn't long enough to discuss everything, but here are some thoughts that
were brought up there:

1. Serialization. 

Looks like we aren't sure what we want to achieve here. We know we want to have
DTD, and we want to be strict about the data. Inheritance is a troubleMaker
here. I don't know if there is any nice way to do something with DTD. We had two
ideas:
-somehow encapsulate (for example in a <super> tag) xml compliant with a
superclass DTD
-force the implementer of the subclass to create DTD that is an "extended"
superclass DTD. by extended we mean that each XML document compliant with a base
DTD has to be compliant with the extended DTD.

Probably both of those approaches imply calling a superclass toXML method at
some point in the toXML method of a subclass.  

One thong that we agree on here is that the implementer should have some freedom
in implementation of the [to|from]XML methods (limited only by the DTD and
inheritance)

2. DAL

There's a lot of different issues so I'll split them into subpoints

2.0 GcRecordSet
We should add a new class to the GcObject Hierarchy. It should be abstract, and
we should use only subclasses implemented by DbDriver vendors. It's
implementation should be as lazy as possible, and off course FAST :)
 
2.1 GcQuery
We need two "types" of queries. Meta-query allowing to operate on tables from
different datasources, and giving the user some abstraction from different SQL
implementations peculiarities, and native (coming in one package with database
driver) that would allow the user to use his favourite features of his favourite
DB engine :) 

2.2 Database driver.
We agreed that the implementation of any database driver should include:
-GcDataSource subclass
-GcRecordset subclass
-possibly also native GcQuery (although it's not necessary)
Driver should be distributed as a separate package.

2.3 GcTable should be general, and rely heavily on the GcRecordset.

2.4 Our DAL will __R_O_C_K__Y_O_U__ :)

3. WIKI
We have wakka wiki installed, but nobody uses it. Sourceforge site is slow, but
it seems, that nobody wants to install wiki on his own machine. TikiWiki is
potentially better than wakka, but it is NOT working. I guess we should
reconsider the whole idea of WIKI ;)

That's pretty all that I remember.

I have also some ideas that have not appeared yesterday:

-Documentation - I've tried out happydoc. It's nicer in use, creates structured
HTML files (we can actually have index page for our docs:) and it even creates
dia file with class hierarchy. On the downside i like the files generated by
pydoc better. I guess it needs some discussion

-SQLite - it looks like a good thing to include (decent performance, bindings to
python), but I still hesitate to call it THE internal data format (lack of XML
support is what bugs me with it)

I had some more in my mind, but I can't remember now.

Comments are wellcome :)
-- 
bye
   Bartek Wilczyñski