> I don't understand what you meant by "InetNetwork appears > incomplete and geared to James v3.0."
cannot compile in 1.3.x missing James integration code ------------------------------- > I'm not sure what you feel is missing, > so please elaborate. Is it just validation? yes, just validation -------------------------------- > I'm thinking that it might make sense to use Ant to handle > JDK 1.3 vs JDK 1.4 the same way that Serge set it up to > handle JDBC v2 vs JDBC v3. A binary from us would be JDK > 1.3 compatible, but if the user builds from source it will > optimize for what they have installed. that's fine; i was unable to compile your test code without the chages outlined below. unless we specify Java 1.4.x, we need to supply code that is 1.3.x compatible. this is a little different then thje JDBC issues .. -------------------------------- > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17 > , 2003 8:58 To: James Developers List > Subject: CIDR and InetNetwork Classes > > Noel - > > Basic functional differences between the InetNetwork and > CIDR classes can be simply summated as 'CIDR supports CIDR > notation' and 'InetNetwork supports IP/MASK', and each > class has their respective support/utility methods that > offers the desired functionality ... > > The primary motivation behind CIDR was to offer James > user's the ability to define sub-networks with CIDR > notation; a standard practice among ISP's and other SMTP > server administrators, and since InetNetwork now supports > CIDR and '*' notation, CIDR has become superfluous. > > The performance difference between the two is noticeable; > CIDR uses clumsy string mathematics for conversion to > BigIntger while InetNetwork uses simpler bit wise > operations on byte arrays. The result appears to be a much > faster test operation with InetNetwork - and speed is > crucial when validating mails in high volume flows. > > When we get down to implementation, it seems CIDR is ready > - used in a commercial situation - while InetNetwork > appears incomplete and geared to James v3.0. It is also > incompatible with Java 1.3, the current platform that > James is committed to. > > The bottom line is what's best for James and it's users we > should do the following - > > [1] > replace the following code > > return InetAddress.getByAddress(new byte[] > { > (byte) (mask[0] & ip[0]), > (byte) (mask[1] & ip[1]), > (byte) (mask[2] & ip[2]), > (byte) (mask[3] & ip[3]) > }); > > > with > return InetAddress.getByName ( > Integer.toString((mask[0] & ip[0]) >> 0 > & 0xFF, 10) + "." + > Integer.toString((mask[1] & ip[1]) >> 8 > & 0xFF, 10) + "." + > Integer.toString((mask[2] & ip[2]) >> 16 > & 0xFF, 10) + "." + > Integer.toString((mask[3] & ip[3]) >> 24 > & 0xFF, 10) ); > > to get InetNetwork compatible with our current > environment. Once we require 1.4, we can replace the code > to use the 1.4 InetAddress.getByAddress(byte[]) method. > Benchmarking with this change does not appear to slow down > InetNetwork's performance enough to be a concern. > > [2] > in normalizeFromCIDR, validation of the CIDR notation > needs to be performed > > [3] > Set up the GenericNetworkMatcher and it's associated > matchers to use InetNetworks and get a version for review > > [4] > Included this new InetNetwork class and associated > matchers in the next scheduled release of James; which I > believe is to be on a regular monthly schedule. > > > James now has the ability to receive network > specifications in the following formats - > > explicit address - 127.0.0.1 > address with a wildcard - 127.0.0* > explicit name - myHost.com > name with CIDR notation - myHost.com/24 > name with IP/MASK notation - myHost.com/255.255.255.0 > CIDR notation - 127.0.0.0/24 > IP/MASK notation - 127.0.0.1/255.255.255.0 > > Collaboration, not competition, is the bond that > strengthens our determination to go on. > > > > _______________________ > thanks, > alan > > ---------------------------------------------------------- > ----------- To unsubscribe, e-mail: > [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > > > ---------------------------------------------------------- > ----------- To unsubscribe, e-mail: > [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
