Hey this is great. We can simply just define the proper store interfaces as you have done. I think we can achieve what you need but really if you need to start a lab project for it do so. If you want to help out with the Directory DNS project then you're welcome to just commit to it. I guess you still have commit rights to Directory since when MINA was hosted there.
Also we should bring up all the ADS interfaces to MINA 2.0. I think this is good for ADS and good for MINA. I spoke to some of the directory peeps about this and we're ready to do it. Trustin told me MINA 2.0 may have a significant performance impact as well. If so we should make the move and start testing with it. Directory and MINA have good effects on one another that benefits the entire community at large. Cheers, Alex On 6/12/07, Julien Vermillard <[EMAIL PROTECTED]> wrote:
Hi Alex I started modifying ADS DNS provider for using MINA 2.0. I'm working on embedded applications and I can't afford much dependencies and extra code (64 MB RAM SBC running 24/7 and a big stick for beating me if the customer need to reboot it). So I choosed to get rid off all the ADS/LDAP/JNDI part and providing my own very simple DataStore for resolving inet address (who actualy generate corrupted DNS reply :( ). I just wanted MINA 2.0 compatibility, small footprint, and just a small server for resolving "IN A" from VoIP devices. I'm not sure those needs fits with ADS DNS provider. I try to make it working but for the moment I'm on other urgent subjet. Julien Le mardi 12 juin 2007 à 09:41 -0400, Michael Mealling a écrit : > Alex, > I know that in my situation I needed a DNS server that I could easily > modify and that didn't come with a lot of extras. What I was building > was a custom synthesizing DNS server for VOIP applications which means I > was creating NAPTR records based on business rules. I modeled much of > what I did directly on the provider in the Directory project but much of > what I needed wasn't there (SNMP agent, query statistics, custom > business rules, etc). (BTW, personal opinion: SNMP must die a quick and > painful death) > I think people who are looking at something like this fall into three > camps: > > 1) People who want a DNS server to replace BIND or some other instance > to do what DNS servers do. > > 2) A well done and maintained set of async DNS libraries for DNS queries > > 3) A DNS server that is capable of high query througput but can easily > modified to handle non-standard DNS applications (synthesized zones, > synthesized records, smart caching, etc) > > IMHO, the PP in Directory handles #1 but includes a lot of things that > most enterprises will have other components to handle. For example, > where I'm working now the people who run DNS and the people who run LDAP > are in completely different departments, with different standards and > different data centers. Having LDAP and DNS in the same app does them no > good. > > Just some thoughts from having done it already... > > -MM > > Alex Karasulu wrote: > > What about working on the DNS protocol provider we have in Directory? > > Let's > > grow community around this. The barrier of entry to existing ASF > > committers > > from > > MINA should be minimal. > > > > What's the benefit of starting yet another DNS server effort? Furthermore > > are there > > issues with the DNS PP in Directory? > >
