Please remember to reply to the mailing list, not the original sender:
http://gnudip2.sourceforge.net/#mailinglist
+++++++++
Creighton MacDonnell wrote:
> I also don't like seeing page after page building up in
> the browser stack (on the "Back" button)
I don't like that behavior either, but I can live with it.
> [...] and I wanted to avoid Javascript as much as possible
Agreed.
> Since you seem to have some experience (with Perl?), perhaps you would
> like to get involved in maintaining GnuDIP? This could be your first
> GnuDIP project.
Heh. I was afraid that was going to be the answer. :)
Sure, if you wouldn't mind addressing the MX issue when you get the
chance (no rush, I've just put on my web pages "don't use secondary
MXes, they're broken"), I'll put the "back to the top" button on my
stack. How soon I get to it will depend on how much it annoys me
compared to other things I have on my plate.
As far as the experience goes, I am a very experienced UNIX systems
programmer (>10 years), and have been programming in general for
about 17 years. I have good perl4-ish skills, but tend to avoid
object oriented perl5-isms, so I'd say only intermediate in that
area. I don't do Windows.
> I don't understand what you mean. When you enter a mail exchanger, it
> will show on the response screen
You're right, it does. I think I was seeing a caching issue.
> Yes. There is a problem with the priorities. I am sure I had this right
> to start with!!!
I suspect the blocks where you're first checking for an mx entry, then
a backup mx entry just have to be flipped in order and made into
an if-elsif instead of an if-if. However, I've not tested that.
> The design is that only one "foreign" MX can be specified.
I don't understand the concept of a "foreign" MX here. What do
you mean by that? And are you referring to the design of GnuDIP
or the DNS dynamic updates protocol? (The latter with which I as
yet have only passing familiarity -- my own package predated
dynamic updates).
> But as I have said, I have little interest in adding new features.
> Again would you like to?
Depends on whether you would classify what I'm looking for as
a weird agenda :)
My operating environment is BIND 9 and Apache. If I were to
get involved, some of they key things I would be looking for
are:
- permitting a single update to affect multiple hosts
(which I believe is already on your wish list)
- permitting an update to result in multiple 'A' records
rather than just one, thus winding up with entries
like this:
host.example.com. IN A 192.168.1.10
IN A 10.10.5.18
IN MX 100 mx1.example.com.
IN MX 200 mx2.example.com.
Think of the case where you have a multiply-homed site
where at least one of the interfaces is on dhcp. The
"fix my particular problem" case is allowing for one
IP via dhcp, and one IP which is static. The general
case would be two or more, any of which can be dynamic
or static.
I realize that these would almost certainly involve a change to
the on-the-wire protocol and thus would have to be planned with
backward compatibility in mind.
My own package (which I am abondoning) permitted the update of
entire zone files for selected subdomains, but the fact is that
I was the only person ever to use it (in support of a split DNS).
That, combined with "views" that have been introduced to BIND
make me consider this to be a feature that is no longer required,
so you need not worry about me trying to add *that* feature ...
My timeline for doing changes like the above would probably be
sometime in the next few months rather than the next few days
or weeks. In other words, they're something that I want rather
than something that is keeping me from having a working system.
--
Devin Reade <[EMAIL PROTECTED]>
--
GnuDIP Mailing List
http://gnudip2.sourceforge.net/#mailinglist
