Not to mention we want to release in the next month, not in the next 3-4 months. If we gut the shaper again, it will require a _LOT_ of testing and work for 1.0.
At this point we will ship a shaping system that works for a majority of the people but for some it will show some limitations. These limitations will be worked on after the 1.0 release. Scott On 10/31/05, Bill Marquette <[EMAIL PROTECTED]> wrote: > On 10/31/05, sai <[EMAIL PROTECTED]> wrote: > > This is in response to a post Chris made (see below) on the m0n0 list. > > > > Personally I would prefer a fully functional shaper with a difficult > > to use UserInterface rather than a very limited shaper with easy to > > use UI. > > To be clear, the limitations occur in a fringe case (CP w/ MAC > filtering and shaping). And really, that's not so much a limitation, > but a CPU hit that I refuse to take, the shaper already takes long > enough. > > > So how about going for the integrated firewall rules with shaping? > > > > I would say that ease of development is more important at this stage > > than ease of use. > > We do that and you can kiss the shaper wizard goodbye. I will _not_ > take responsibility for a ruleset that permits more than you'd like. > Which means that there will be no VOIP rulesets, no P2P rulesets, > _nothing_ to limit bandwidth, you'll have to enter all the rules for > that in by hand. There's logic to why shaping is different from > firewall rules - we do it on a port by port basis, there's no > 'magical protocol decode' anywhere. BTW, Scott wrote it that way 12 > months ago before changing it back to ipfw and then subsequently me > figuring out how to ditch ipfw for it (which incidently made the > shaper work a LOT better). > > Modifying PF to handle something other than a pass/block I believe is > doable and something I plan on looking at (although I know of at least > one other user on this list that has asked similar questions - I don't > know if he's put any effort into solving the issue or not though). > > --Bill >
