Please remember to reply to the mailing list, not the original sender: http://gnudip2.sourceforge.net/#mailinglist
+++++++++ Devin Reade wrote: > > #define OFF_TOPIC > > First off, thanks for your efforts on this package. GnuDIP's > state is now at the point where I am in the process of migrating > my users from a functionally similiar homegrown app that I wrote > a few years back. There are still some features that GnuDIP > doesn't have, but it is more suited to large numbers of users than > my package was. Great. > (And even better, I don't have to maintain it!) The problem is, I am not sure that I want to either. I would like someone else to join me. The problem is that whenever I talk to someone who is interested in doing so, they have a wierd agenda that would basically completely rewrite it (For example to have it only work for tinydns!! Seriously.). They are of course free to take the code and do that if they wish, but they will have to do it without me > Anyway, to the point: It would be nice if in the GnuDIP web > interface if there was a "return to main" button on every page > that would take the user back to the point where the user's > main screen is displayed just *after* a successful login. Right > now, the user either has to go back to the main link and log > in again, or he has to use the 'back' button a few times > (and consequently has to be careful not to repost old form data). You may have a point. There were buttons sort of like this in the old 2.1.2 version. But they behaved a bit wierd. I felt I either needed to remove them or change the way they worked. I also don't like seeing page after page building up in the browser stack (on the "Back" button). I always find this irritaing when I use other peoples intefaces. But this could not be avoided without using Javascript, and I wanted to avoid Javascript as much as possible (since it is still not very portable, if you get carried away), and certainly did not want GnuDIP to require that the browser have it turned on. Since it was not absolutely required, I chose not to do it. However, it is irritating if you use a "Quick Login" URL to login in, and then you cannot go up to the login screen without modifying the URL line. > As most (all?) of my users will be using the command line interface > after their initial setup, I consider web interface issues to be > of fairly low priority, but the current behavior *does* count as > a bit of an annoyance. 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. Devin Reade also wrote: > > In the web interface, the way that the user's MX configuration > is displayed is non-intuitive: > > 1. When an MX is set and the user returns to the web > config, that MX is not shown. Only by querying > the nameserver directly do you see that there is > an MX record in place. I don't understand what you mean. When you enter a mail exchanger, it will show on the response screen It will also be there the next time you log in. If you use the "Back" button, then of course it will not show unless you "Reload". > 2. The semantics of the "secondary MX" button are unclear. > When I first tried to use it, I expected that by > entering a FQDN in the MX box and clicking on the > secondary button, that the entered FQDN would be > listed as the secondary MX. Instead, I went from this: > > host 300 IN MX 100 mx-main.example.com. > > To this: > > host 300 IN MX 200 mx-main.example.com. > host 300 IN MX 100 mx-back.example.com. > > As you can see, the priorities in the MX records are > reversed. Yes. There is a problem with the priorities. I am sure I had this right to start with!!! I made a "fix" for this in the GUI that must have screwed it up. When I provide macdonnell.ca as an MX server, I get: tester.ddns.ca. 60 IN MX 100 macdonnell.ca. When I indicate that the MX server is actually just a backup server I get: tester.ddns.ca. 60 IN MX 100 macdonnell.ca. tester.ddns.ca. 60 IN MX 200 tester.ddns.ca. So macdonnell.ca will get tried before tester.ddns.ca. And this is backwards. I will fix this as soon as I have a moment. > I would content that a better interface would be to have two entry > boxes, one for the primary MX and one for the secondary MX. > Furthermore, when the form is displayed, any current MX records > should be displayed in those fields just as the username and > email address are currently displayed. The design is that only one "foreign" MX can be specified. If you click the "Backup Mail Exchanger" button, then another MX record for your dynamic domain name is supposed to get inserted "in front" of the foreign one. That way your box will be tried first, and if it is not reachable, the foreign MX will be tried. I will fix the problem you found. I have a couple of fixes for the FastCGI scripts (which I use on my site) that I have been meaning to apply too. But as I have said, I have little interest in adding new features. Again would you like to? -- Creighton MacDonnell http://macdonnell.ca/ -- GnuDIP Mailing List http://gnudip2.sourceforge.net/#mailinglist
