[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Design Documents

On 2 Oct 1997, Manoj Srivastava wrote:

>  the backing store (err, cache)? I am wondering if I should instead
>  just write a topological sort that uses the backing store data (it
>  may require an additional linked list or two threading though the
>  data).

I would. If you need anything more let me know, it's probably quite easy
to add more lists through the datastructures. The only limit is that you
may not modify the cache in memory (it's mmap'd readonly).

> 3. Modules and interfaces
>  a) The user interface module: Look at Behan Webster's documentation.
>  b) widget set, related closely to above
>     Could some one prewsent design decisions of the widget set here?

Hm, that will take some time :> Look in deity/widget.cc for a quick
overview.. I want to prepare alot of sgml about it someday too.. Ben? Any
>  c) Update Module
>     Distinct versions of the same package are recorded separately, but 
>     if multiple Packages files contain the same version of a package,
>     then only the forst one is recorded. For this reason, the least
>     expensive update source should be listed first (local file system
>     is better than a remote ftp site)
>      i) FTP methods
>     ii) mount and file traversal module(s)?
>    iii) Other methods ???
>  d) Status file parser/generator.

The parser is part of the cache generator. The generator I haven't quite
decided on what it should do exactly. It has to be -very- safe.

>  e) Package file parser/generator (related to above). Handle multiple
>     Packages files, from different sources. Each package contains a
>     link back to the packages file structure that contains details about
>     the origin of the data. 

      See cache.sgml, it has quite a lengthy discussion of this entire
>  f) Dependency module
>     i) dependency/conflict determination and linking
>    ii) reverse dependency generator. Maybe merged with above
       Already present in the cache..
>   iii) package ordering/event generation module

We should talk about this, I want to design somekind of extendable
dependacny thingy -- what I have been working on now is not too agreeable.

>  g) module to interact with dpkg
 This needs some thought too..


Reply to: