Re: Package Pool Proposal
On Tue, 23 Nov 1999, Ben Collins wrote:
> On Tue, Nov 23, 1999 at 06:08:41PM +0000, Jules Bean wrote:
> > On Tue, 23 Nov 1999, Ben Collins wrote:
> >
> > With that proviso in mind, my gut feel is that this 'shape' of problem is
> > one well solved by relational databases...
> >
>
> While traditional databases might be superior in their "benchmarks" and
> significant indexing and other data specifics. LDAP is geared better for
> this type situation for several reasons:
I wasn't thinking benchmarks. I thinking the ease with which you can
acheive powerful data manipulation.
>
> 1) It is easily accesible via the network. IOW, it's widely distributable
> and is aimed at being replicable (something we need for our application).
> IMO, this is the biggest reason.
Excellent point. Of course, this is a point about the implementation of
LDAP servers rather than a fundamental one. That doesn't make it less
valid.
I didn't know we needed to replicate. We can, of course, simply copy
postgres files (by, e.g., rsync)
>
> 2) It is simple. The filtering is easy to grok, even for beginners. This
> way, no one has to be a SQL (or other) expert in order to use it.
>
I may have to take your word for that.
> 3) It's very light weight. The perl module that supplies scripting as a
> client is only about 75k installed (nothing else is needed besides perl).
>
Perl DB scripting code is fairly lightweight.
> 4) It allows us to merge other things. For example, our maintainer db is
> already LDAP based, and is used for, among other things, our system
> accounts for each developer, and PGP keys. Our BTS could eventually be
> merged with it, and have the bugs become child entries for the packages
> they pertain to, and even make the bugs version/arch specific for the package.
Good point. Although I'm not sure it's the right form for the BTS either
;)
>
> 5) Expandable. We don't have to rewrite the entire schema and table layout
> if we want to change things. LDAP directories are very open and even allow
> multiple values for a single field (the row/column structure does not
> apply). It allows inheritable objectClasses.
Silly point :) DB's as expandable as they are designed to be. 'Even
allowing multiple values for a single field' is *not* an advantage.
>
> 6) Access control. Access to the directory can be controlled down to a
> single field per user. Users can even own entries (perhaps package/source
> entries could eventually be owned by their maintainers, and use PGP for
> auth) and access given to them based on that ownership to make changes
> that other developers can't.
Implementation issue. But still an important one, you're right.
Jules
/----------------+-------------------------------+---------------------\
| Jelibean aka | jules@jellybean.co.uk | 6 Evelyn Rd |
| Jules aka | jules@debian.org | Richmond, Surrey |
| Julian Bean | jmlb2@hermes.cam.ac.uk | TW9 2TF *UK* |
+----------------+-------------------------------+---------------------+
| War doesn't demonstrate who's right... just who's left. |
| When privacy is outlawed... only the outlaws have privacy. |
\----------------------------------------------------------------------/
Reply to: