Re: Package Pool Proposal
On Tue, Nov 23, 1999 at 07:17:27PM +0000, Jules Bean wrote:
> On Tue, 23 Nov 1999, Ben Collins wrote:
> >
> > 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)
Well, being that everything about Debian wreaks of networked cooperative
development, it's a must :) Rsync is "doable", but it isn't as instant as
a replcated LDAP system. Also, depending on the systems involved (ie.
slink/potato, hurd/linux, big endian/little endian), it might not be feasible
to use a hard database file type (DB2, DB1, hashed, etc..).
>
> > 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.
But not as simple. If you are talking direct DB_File calls, then you are
talking about months of development/testing/implemetation to get an entire
database system setup, where as with LDAP it's already done (the storage,
structure, threading, replication, ACL's, etc..)
> >
> > 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.
Tracking multiple values is an advantage. One the DB2 itself has (I was
working under the example of a SQL database). For example, suppose a
source package contains 3 binaries. One field called "binPackage", would
be used 3 times for the source entry. So now someone can search for
"binPackage=libfoo1" or "binPackage="libfoo*", without worrying about a
comma seperated list, or other tokens.
> >
> > 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.
Well, you are arguing about the possibilities of one possible
implementation against the real advantages of one real implementation :)
Note that the OpenLDAP server (slapd) uses DB2 for it's backend storage on
the filesystem. It's threaded, and pretty fast (of course indexing must be
setup appropriately). You can also script the backend data source (eg. I
have a tcl scripted backend to the BTS, to make the BTS data available
from LDAP).
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org - collinbm@djj.state.va.us - bmc@visi.net '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: