Hi Rob, this is a great report! I think it will be very useful when we'll define our goals and how to proceed.
I agree on almost all of your concern. Let's track down some incompatibility between your view and other's people opinions I read in this DNS thread. Java 5: is this a big requirement for you? Personally I have no big requirement for platform and I would be fine with a java5+ library, but I think many users out there have 1.4 compatibility as a requirement. Record mutability: how often do you need this? Have you compared real performace tradeoff between mutable records and "immutable records+clone" approach? I think that when the records are used by multiple threads then immutability have a great impact on performance. (e.g: if you return an immutable object from the cache then the user can read it and do whatever he wants, otherwise you cannot ever return to the user a record from the cache) Thank you, Stefano PS: it would be really cool to have a "preview" of your code, even if it is far from be complete. Rob Butler ha scritto: > Having worked with dnsjava, I felt there were some significant issues with it > for the types of applications I wanted to develop. > > Specifically, > > * I want mutable objects, that can be selectively made immutable. > - dnsjava records are always immutable. > > * I want my objects to always work the same no matter if a message has been > "built"/marshaled/unmarshaled. > - some methods, specifically on the Message object behave differently if > you are working with a message that has been parsed from the wire VS one your > are building programatically. For example, if you call Message.setTsig(..) > and later call Message.getTsig() you would expect to get back the TSIG you > set previously. With dnsjava you only get a TSIG back from getTsig() if the > message was parsed from the wire. > > * I want all overloaded messages to behave similarly, as a Java coder would > expect. > - Message.toWire() and Message.toWire(int) in dnsjava have some > differences in how they behave. For example, if you had called > Message.setTsig(..) you would expect the TSIG to be written in the DNS > message when calling .toWire() or .toWire(int). The TSIG is only written > when .toWire(int) is called. > > * I wanted a better OO design and I wanted to use Java 5 language features. > - a DNS Header as a separate object doesn't really make a lot of sense to > me. It only has worth as part of a message. It should at best be an inner > class that is not directly exposed as an object outside of Message, if such a > class even exits. All operations that are in dnsjava's Header should be on a > Message object. > - Because Header is a separate object from Message, it is possible for > strange things to happen in dnsjava. For example, your header could say > there are 2 records in the answer section, even though there are none or vice > versa. > - There are response codes for messages, TSIGRecords, and a few other > record types. Even though the response code for NOERROR is always the same > value, the various response codes should probably be inner enums of the > appropriate object types. It wouldn't make sense to specify an NXDOMAIN > response code for a TSIGRecord, but with dnsjava you can. > - Data class only makes sense on records. There should probably be an > inner enum on Record that defines what they are instead of it being a > separate class. > - dnsjava doesn't track some data that it should. For example, if you > parse a message off the wire, you should be able to do something like > TSIG.verify(incomingMessage), because the incomingMessage should know what > the bytes were on the wire. dnsJava doesn't keep track of the original > bytes, so you have to. Because of details I won't get into it's necessary to > track the original message bytes for TSIG validation. You cannot simply > re-construct the byte stream by calling Message.toWire(). > > * I wanted more separation between a DNS parsing library and things built > with it. > - For example, dnsjava includes a resolver and a minimal DNS server along > with all of the parsing code. It's great this is supplied as part of the > project, but they should be separate modules (jars) within the project. If > your building a DNS server using dnsjava there is no reason to have dnsjava's > server and resolver present. It's not a big deal that they are, but i feel > they should be separate. > - I wanted the parsing library as separate from the IO implementation as > possible. > > * I wanted a better exception hierarchy that would allow a developer to know > exactly what went wrong instead of just a single exception for all errors. > > * I wanted support for evolving standards like NSEC3, IDN, etc. > > * I wanted to do everything possible to make it as fast as possible w/o > trading off good design. > > * I wanted everything fully javadoc'd. > > Considering all the above, and more, I thought starting from scratch would be > the best approach. I don't want this to sound like a dnsjava bash fest > though. Brian's done some great work developing dnsjava and making it open > source. I've learned a lot from using it and reviewing it's code. I'd just > like to develop something with a better "Java feel". Consider it dnsjava 2.0. > > Rob
