8 Feb
2016
8 Feb
'16
11:51 a.m.
On Mon, Feb 8, 2016 at 7:29 AM, Brian Kantor <Brian(a)ucsd.edu> wrote:
On Mon, Feb 08, 2016 at 05:22:48PM +0200, Tal Raveh
wrote:
Like you've said, this is probably not the right place or time to
discuss the choice of database. However, I just want to go on the
record to say that I really *really* like that idea of using LDAP for
this purpose.
Since LDAP is standards based, every language you can think of has
libraries for reading from or writing to it. It would make future
tools based on the data very easy to create and negates the need to
expose a portal API. The portal would just be another one of the
tools talking to LDAP, but with more write privileges than most.
Availability would also be greatly improved as the "master" LDAP
controlled by Brian could propagate changes to any number of read-only
copies hosted by various networks all over the world (just like DNS
servers with a hidden master). For example, once we have a whois
service up and running, we can simply point each whois server at its
own read-only LDAP copy so traffic doesn't impact the master.
Certificate authentication is also possible with LDAP which means it's
likely we'd be able to support use-cases where updates need to be made
securely over a RF link without using encryption to create a private
channel for a password.
</End rant style geek-out on LDAP> ;)
from the portal and few of them result of the
automatic script.
The portal doesn't have that information yet. It doesn't exist.
That's what this whole exercise is about, getting that information
and storing it into the portal. After that, we can consider changing
databases if there's a good reason to do so.
- Brian