Wow you guys are getting real deep. Perhaps we should take these technical
conversations over to the ldapd dev list for now. This place is for
incubator stuff not tech stuff so we'll continue at ldapd-devel after this
bridge email.
BTW I think BerkeleyDB was faster than the jdbc based implementa
BTW the graph representation sounds very interesting I'd like to talk more
about it. It sounds like a great way to store objects in an ODBMS.
-Original Message-
From: Jim Wright [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2003 7:50 PM
To: [EMAIL PROTECTED]
Subject: Re: Offici
That's deep stuff Jim - u got me thinking. BTW we would love for you guys
to give us a good critic of the backend database design. Perhaps we can go
from there.
Alex
-Original Message-
From: Jim Wright [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2003 7:50 PM
To: [EMAIL PROTE
Hi Jim,
The original pre-release versions of LDAPd were implemented with a
BerkeleyDB backend, with custom index management etc, much like the
openldap articale you reference. Those early designs, did have a contracted
backend store interface defined (thank-you Mr magic - Alex), and indeed
the
Thomas works for a commercial RDBMS company. License change has been
raised before :-( I'm a part time committer on that project.
So my recollection is correct, that the stumbling block is Thomas' name
credit, yes? Too bad, since otherwise it would seem to be a good fit
for
db.apache.org.
I
Alex and Brian,
Regarding the relationship between RDBMS and LDAP...
I believe this document says why RDBMS is wrong for LDAP:
http://www.openldap.org/faq/data/cache/378.html
On the other hand IBM have implemented LDAP in DB2. See:
http://www.research.ibm.com/journal/sj/392/shi.html
Since rea
Paul,
>>>I would personally recommend to ask the hsqldb guys
(http://hsqldb.sf.net)
>>The license is compatible except, as I understand it, for the fact that
the
>>original author wants his name
> Thomas works for a commercial RDBMS company. License change has been
> raised before :-( I'm a p
Noel,
I would personally recommend to ask the hsqldb guys (http://hsqldb.sf.net)
Absolutely. I had that in my original post, pre-editting. The license is
compatible except, as I understand it, for the fact that the original author
wants his name
Thomas works for a commercial RDBMS compan
Noel has a very good idea for providing bundles of JNDI ObjectFactorys and
StateFactorys for the various published LDAP schema objectclasses so you can
read them as objects from a relational entry.
So these factories for doing O/R would be packaged into the server and clients
as a jar. For e
Would be great to have you involved. If you would like to for the time being
we can leverage the sourceforge infrastructure. Let me know if there's any
particular aspect you want to work on.
You would probably be most interested in the ldapd.server.backend source
subtree. Take a look at th
Right sorry - just saw your email now. My last email basically reiterates
your points.
Alex
>
> From: Brian McCallister <[EMAIL PROTECTED]>
> Date: 2003/09/11 Thu PM 03:00:37 EDT
> To: [EMAIL PROTECTED]
> Subject: Re: Official Apache Directory Project Proposal Submission
>
> Argh,
Brian,
Directories are highly specialized databases because they store and search on
data. That's pretty much the extent to which they overlap. LDAP and X.500
are also network protocols and involve alot more than just the relational
aspects they share with most databases. Besides their acc
I wasn't so much looking for projects to put under the DB wing, but
thinking of people who might be interested in LDAPd. An LDAP most
definately is *not* an RDBMS, but it is a protocol for accessing
hierarchical databases. After filesystems and DNS, ldap's are probably
the most widely used hier
inline
On Thursday, September 11, 2003, at 02:24 PM, <[EMAIL PROTECTED]>
wrote:
Both and RDBMS and an LDAP server are databases really.
This is exactly what gets me excited. OODBMS's are basically dead (sad
as they are nice to develop on) O/R tools are getting as easy to
develop on as the nat
Jochen Wiedmann suggested:
> Noel J. Bergman wrote:
> > There are some other candidates that the DB PMC could look into
incubating
> > and adopting. For example, http://axion.tigris.org/ is a rather obvious
> > candidate, especially considering the committer list (geir jvanzyl
mpoeschl
> > rwald).
I wasn't so much looking for projects to put under the DB wing, but
thinking of people who might be interested in LDAPd. An LDAP most
definately is *not* an RDBMS, but it is a protocol for accessing
hierarchical databases. After filesystems and DNS, ldap's are probably
the most widely used hier
Argh, keep emailing with unsubscribed account... My apologies if a
moderator approves a clone of this message later
I wasn't so much looking for projects to put under the DB wing, but
thinking of people who might be interested in LDAPd. An LDAP most
definately is *not* an RDBMS, but it is a
inline
On Thursday, September 11, 2003, at 02:24 PM, <[EMAIL PROTECTED]>
wrote:
Both and RDBMS and an LDAP server are databases really.
This is exactly what gets me excited. OODBMS's are basically dead (sad
as they are nice to develop on) O/R tools are getting as easy to
develop on as the nat
Noel J. Bergman wrote:
There are some other candidates that the DB PMC could look into incubating
and adopting. For example, http://axion.tigris.org/ is a rather obvious
candidate, especially considering the committer list (geir jvanzyl mpoeschl
rwald).
I would personally recommend to ask the hsq
> you might also want to say something about this on
> [EMAIL PROTECTED] as an LDAP is sort of a db =)
> A high-profile new project could help liven up DB some ;-)
I think that naming and directory services are sufficiently different from
an ODBMS or RDBMS.
DB might want to consider adopting Jak
Brian,
Actually we have implemented a rudimentary relational database (non-sql)
inside the server specifically to optimize for LDAP, however the engine core
could be reused for an RDBMS. Both and RDBMS and an LDAP server are databases
really.
Actually the combination of an RDBMS coupled
Awesome!!!. Please let us know as soon as someone signs up for "shepherd"-ing this
contrib. I'll
start the looking at "initial steps stated in the root STATUS file of our CVS" soon.
-- dims
--- Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote:
> Davanum Srinivas wrote:
> > looks like there are no ob
Am writing up a post, but you might also want to say something about
this on [EMAIL PROTECTED] as an LDAP is sort of a db =)
A high-profile new project could help liven up DB some ;-)
-Brian
On Wednesday, September 10, 2003, at 03:53 PM, <[EMAIL PROTECTED]>
wrote:
We're at the disposal of the
Nicola Ken Barozzi wrote:
...
contributor agreements signed
I spoke to soo, maybe we already have them ;-)
Section 4: identify the initial set of committers
# Jochen Wiedmann (JaxMe? project founder, formerly perl.apache.org)
# Davanum Srinivas (ws.apache.org)
# Robert Burrell Donkin (jakarta.ap
Davanum Srinivas wrote:
looks like there are no objections so far and we can stick to the names of cvs modules
and mailing
lists.
What is the next step? (incubator PMC VOTE?) please advise.
As the ws PMC has already voted in the project [1] (correct me if I'm
wrong), the project is already in inc
looks like there are no objections so far and we can stick to the names of cvs modules
and mailing
lists.
What is the next step? (incubator PMC VOTE?) please advise.
-- dims.
--- Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote:
> Paul Hammant wrote:
> > +1
> >
> > Proviso :-
> >
> > CVS repos sh
26 matches
Mail list logo