The list is here: https://lists.sourceforge.net/lists/listinfo/registry-list
And I'm CC in the reply.
We had some severe DNS problems due to a bad registrar but we are back now.
We don't have distributed configurations in mind for now, but I understand its importance. We are trying to be simple with a reduced scope, so other projects can use Elektra in simpler ways. To build an ecosystem of softwares using Elektra is the most difficult and important point now. So distributed configurations seems like a desired step for the future.
We what we already have now, I can outline how to build it. We'll need to define some specifications for addresses, and of course, a communication protocol.
Any help is welcome.
Regrads,
Avi
On 10/17/06, Eric A. Hall <[EMAIL PROTECTED]> wrote:
Hi,
FYI the links to the presentations (both OO and HTML) are broken; they
point to libelektra.org which does not resolve
Is there a mailing list for architectural talk or is this a one-man
project right now?
I did some protocol work on a distributed directory for an IETF working
group and I would like to add to the discussion. Right now it looks like
you are going for simple, but there are some things you will run into
pretty hard if you don't design for them early. IE, you need a registry to
avoid collision (either make your own, or defer to something like OID tree
for third-party registration (but then you need to map between OID and
friendly names, which is painful). ACLs and operational attributes
(creation time, creation user, etc) look like they are partly reflected in
the API list, but I don't see any discussion elsewhere.
There is a big need for inheritance, referrals and aliases (they are all
different) so that netadmins can do things like define global policy and
all systems in the network read/cache the global policy. Also if you do a
good directory, you will see distributed applications want to query the
directory as part of a distributed operation (ie, ask the directory for
mailstore host) and so you need to plan for distributed operations.
As should be obvious, it seems to me that the initial design should really
look hard at distributed operations. Local operations are easy.
http://www.ehsco.com/misc/I-Ds/draft-ietf-crisp-firs-arch-03.txt is the
core architectural spec for the distributed directory, which used LDAP as
the transport service. I do not think that is the way to go for something
like this, but I'd be happy to bring some of the working knowledge over if
you'd like.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
--
blog: http://avi.alkalay.net/
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Registry-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/registry-list
