On Mon, Feb 8, 2016 at 7:29 AM, Brian Kantor Brian@ucsd.edu wrote:
On Mon, Feb 08, 2016 at 05:22:48PM +0200, Tal Raveh wrote:
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
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> ;)