Below are some ideas to keep in mind for future versions of Maintain. These may be features, or they may be just suggestions for operation. Either way, here they are.
IPv6, DJBDNS Location Syntax, Multiple IPs per MAC, Multiple MAC per Host
At first it probably seems odd for me to put these ideas together, the reason I do will become apparent shortly. Basically the changes that are required to make one of these occur inherently lend themselves to including the others. The idea here is very simple. you abstract out the hardware address and the IP address from their Host and make them into 2 new tables. You also add in a third table that will act as the Location syntax table. Roughly the visiion for these tables that I had in my head is the following:
IP
| id |
ip
|
host.id
|
loc.id
|
mac.id
|
version
|
| |
|
|
|
|
|
id - primary key, auto increment
ip - The actual address. This will probably be stored as a string. If it is to be an IPv6 address you must fully expand the address including all :: and then push the string together. That would mean that ::1 would first be converted to 0000:0000:0000:0000:0000:0000:0000:0001 and then stored as 00000000000000000000000000000001. This method may seem odd, but it allows for there to be database level sorting, as even with the hex numbers in place, they will still order themselves appropriately since all numbers precede letters, and the letters will be stored in alphabetical order. For consistency reasons it is important that their case are all the same.
host.id - Foreign key to the host id in the host table that is registered to that address.
loc.id - Foreign key to the location in the loc table that this address responds to. The conecpt of location syntax is that someone can resolve the same name to a different IP based upon where the request came from.
mac.id - Foreign key to the address.id in the address table
version - Version of the IP protocol that the address is
Address
id - Primary key, autoincrement
address - the actual HA, stored without :s
host.id - Foreign key to the host id in the host table that is registered to that address.
Loc
id - Primary key, autoincrement
name - name of the location
... - anything else you may need, the total number of columns actually required is currently unknown.
Summary
By implementing the tables above, it should be obvious how this addresses the above mentioned issues. IPv6 is introduced because the IPs are now abstracted out one level, enabling you to change them quite simply. The DJBDNS Location syntax is now possible since you have an ability to tie an address to a location. Since you now have a foreign key between IPs and hosts you can now create a one-to-many relationship. The same can be said for hardware addresses and hosts.
Version Numbering
I am a huge fan of release early and release often, and Maintain is now in a position where it can start following that methodology more closely keeping life in the application. Because of the release early, release often mentality, I'm going to suggest the version numbering system be changed slightly. Instead of only recognizing one decimal point (3.0) I propose that instead we add a second point. (3.0.0). The furthest right value could be incremented when bug fixes are issued or module hooks added, the middle digit when database changes occur, and the major revision number (left number) if significant amounts of the code base have changed.
In the name of keeping our customers happy, I highly advise making use of patches for critical bug fixes. You may make the packages bug fixing clumps, but the end user shouldn't need to completely reinstall Maintain everytime a bug is fixed, it should be something simple for them to handle. In the past, Maintain has specified that developers contributing patches should submit them as a runt diff (diff -ruNt) these unified diffs could then be applied with patch from the root directory of Maintain.
