my $0.02 On Fri, 2004-02-20 at 12:12, Tyler Larson wrote: > I agree that keeping the discussion on this list is the best idea. Brent told > me the same thing back when I started getting involved. This list has very low > volume, and a relatively small group of readers, so it should be fine. It also > makes for a very easy way for others not working on the project to keep track > of our progress and offer suggestions/help. Now that I'm a bit more familiar with this list's level of usage, I too agree that we can keep the devel discussion here, provided the fedora people don't mind. > I have a couple of servers at ServerBeach running FC1, and I already have > subversion server running on one of them. We *could* use it if we wanted to, I > was just checking to see if anyone had a better idea. My server is hosted in > a "bomb shelter", so it has 100% uptime, high bandwidth, a stable connection, > and redundant everything. Sure beats DSL. Our best bet is the public Fedora CVS > server, once they get around to setting it up, but mine works well too. > My primary intentions for using a forge were to give the project a permanent, third-party home and be able to use the management features such as task delegation and news and website. We could keep the mailing list here, and the source at Jeff's site and still use the forge for those things, if everyone thinks these tools would be helpful. If we start adding more people to do mundane tasks, this will be very helpful. Update: I just had lunch with Tanner (TriLUG admin) and they're willing to move to Subversion for us. The bonus of this is that we won't have to deal with administrating it ourselves, and the code will have a permanent home if any of us decides to move on later. > > I had a look at your parsing code and I'm quite impressed at how thorough it > is. Granted, I can't get it to run on my machine for some dumb reason, but I'll > try and work that out. > > > Here's some of my thoughts about coding: > > Our interface should be "compliant" and all that: check > http://fedora.redhat.com/participate/developers-guide/ for some basics. > Particularly important is the Gnome HIG. [ > http://developer.gnome.org/projects/gup/hig/1.0/ ]. Of course, you all know > that :) > > I haven't seen any official fedora-python coding conventions listed, so if any > of you have seen anything, let me know. For now, though, we ought to be good > just following the same style as s-c-network and up2date. Make it clean, > document your functions, and use existing libraries for things like command- > line parameter parsing. > Sounds good, I'd like to get another person in on the project to do research on these types of things (and others) and be able to report on how these directly affect our code. > > As far as rule parsing is concerned, here's a few things to keep in mind: > > * We should be liberal in what we accept as far as rule symantics are > concerned. We can never be totally certain that what we don't know how to parse > is an invalid rule. If someone comes up with a new firewall module, the > iptables firewall rule is very likely where that module's configuration will > go. When we can't parse a rule, we ought to let the user know, but I'm not sure > we should do anything drastic like mangle it or throw it out. On the other > hand, if we try to re-insert an invalid rule back into the kernel, it will barf > reject the whole ruleset--something to avoid. So... Maybe we should validate > the rules and display a warning if we don't understand them before sending them > off to the kernel. I agree that we need to be liberal with parsing unknown things. I don't think we need to let the user know we couldn't parse something with a alert or anything, but instead we should make a way for extra arguments we don't know about to sit in an extra string (and text input box in GUI). If we don't know about an extension the Rule class should have a string to keep unknown tokens. > * Remember that the "native* format for any parameters is text--we read it in > as text, and we write it out as text. Once again, I'm not sure what the best > method to use here is, but when we take a parameter (such as an IP address) and > convert it into its numeric representation for internal storage rather than its > textual representation, we're introducing an extra step and increasing the > complexity of our application. Now, if we're going to do any numeric > comparisions using the address, we have to have it in numeric form, so that > step is necessary. I guess what I'm saying here is that we have to decide which > parameters should be "transparent" (e.g. numeric form) , and which ones should > be "opaque" (e.g. textual form). Making parameters transparent allows for > greater flexibility, but introduces more opportunity for error. Leaving them > opaque reduces the chance of error and bugs, but it less useful. This is a good point. It also brings up the issue of resolving hostnames. I believe it's possible to put a hostname/metric into a file and have iptables-restore resolve it when putting it into effect. I think for now we should stick with just IPs (iptables-save outputs numerically) but it's something to think about. Someone out there may have a file they've edited themselves with a hostname instead of IP. In general I think we'll just have to wing it when coding as to whether to make things transparent or opaque. For the sake of programming the UI I think having a all the switches at least be transparent is necessary. Remember, for grunt work like all the extensions, we can get other contributers to mimic the style of previously built extensions. > > My original concept application used one-time parsing of parameters (i.e. > classifying the "chunks" of a rule), but relied on on-demand interpretation of > parameters (i.e. converting textual addresses to numeric ones). I don't know if > that's the best way to do things, but I figured it would be best to bring up > the issue and let people think about it. The way I'm seeing the code going so far is that we're doing a load and parse before getting to any UI or editing. I think this is the most straightforward and I can't think of any particular reason to do otherwise. > > Cheers > > -tylerl -- Timothy A. Chagnon <tchagnon@xxxxxxxxx>