On Jul 28, 2007, at 4:49 PM, Thomas Lotterer wrote:

> I want to suggest we create and maintain a document describing
> architectural decisions of rpm5.org. The document should collect a
> digest of inputs regarding important or frequently discussed topics on
> rpm-devel which require ending up in a decision where to go next (not
> necessarily forever). Those decisions should reflect consensus and/or
> commitment previously gathered on the list. The architectural decision
> would then stay in force while the inputs leading to the decision  
> remain
> the same. The goal is to guide developers where to go and drive users'
> expectations. Without any rules, we run risk of wasting precious
> brainpower with useless discussions and creating ping/pong commit mess
> etc. Finally, I'd like to see some stochastic development replaced  
> by a
> little bit of engineering.
>

OK. There's nothing stopping anyone from doing whatever, but if you need
rules and engineering and whatever else, well, I guess you'll have to  
make
a proposal.

So far, most of what has been implemented in thge last month is to  
permit maximum flexibility
and portability. But if you wish to restrict vendor choice(s) through  
engineering
documents, well have at!

> To be more precise:
> - the document should be in the repository,
>   maybe ARCHITECTURE or docs/architecture
>

OK.

> - one decision I'd like to see is whether rpm5.org
>   is going to support BDB, SQLITE, both, others etc.
>


The decision to use inverted lists, with the open/close copen/cclose,  
get/put/del
methods is architectural.

That architectural decision was made A Long Time Ago. My guess is  
that sequential
reading of headers turned out to be pig slow.

The choice of database implementation has nothing whatsoever to do  
with architecture,
just as one can do object oriented programming in fortran, C, Bourne  
shell, whatever.

But sure you don't want to use Berkeley DB. Use whatever else you  
wish to implement.
Support for the methods I mentioned can be whipped out in a week,  
just like the
sqlite implementation was.

> - another one will be a discussion of how rpm5.org
>   uses release identification and signification
>

You'll need to explain your request a bit further.

> - basically the document will correlate with our roadmap,
>   but it also includes the reasons that led to decisions
>

What reasons?

> I'm not in favor of paperwork but I expect this to be valuable.
>

To whom?

73 de Jeff