Hi. I think we only need from ufw frontend: - Method for set/get an SPLIT fields from rules (separated IP to, Port to, protocol to, rule, IP from, Port from, protocol from). - No warning messages using the ufw frontend.
It's more interesting the Dbus, because all can start without root password and use the Policykit. Thanks Jamie. Marcos. On Thu, 2008-12-11 at 20:00 -0600, Jamie Strandboge wrote: > On Tue, 09 Dec 2008, Roderick B. Greening wrote: > > I was wondering if you both have any timeslots available this week that > > we > > can get together and start to hammer out a spec on this cooperative > > effort? > > > Sorry that I am only getting to this now. Unfortunately, I am pretty booked > for Friday, and have meetings this evening. However, I'll respond inline > below. > > > Here's what I see: > > > > 1) ensure ufw presents a complete API for front-end development > > - what functions are currently exposed > > - what functions are missing or need changes > > I will obviously adjust this where it makes sense. > > > - does the current ufw package install correctly to allow > > us to import the front-end API into other interfaces > > I may not have done this correctly, but will look into it. > > > 2) creation of a ufw-gui-common deb package > > - to contain common methods and tools to access ufw API > > - possibly contain shared resources (icons like the shield) > > - cannot contain anything specific to any toolkit (like GTK/Qt/KDE) > > - ufw-kde and gufw should share/use this common base > > - any GUI front-end should talk via these methods and not via > > system calls or by talking to ufw > > With the exception of the icons, this was what I was hoping to achieve > within ufw itself. The ufw cli command should probably use whatever we > call the 'common' base. Maybe it makes sense to split it out into a > different package, but my feeling is since all of these frontends > (including ufw itself) depend on this, but the ufw-cli command is so small, > it would just be part of the ufw package for now. I'm open to changing this > if deemed appropriate. > > > 3) we need to discuss whether to merge any or all of these into a > > common code base which generated the appropriate packages. > > - do we keep ufw-common on its own or merge with ufw code base > > - do we merge ufw-kde and gufw together > > - discuss what is appropriate (pros/cons) > > > Perhaps I don't understand how ufw-common is different than frontend.py, > can you clarify? > > Also, you can look at how src/ufw uses frontend.py. The flow is it > basically takes user input and shoves it into a few different > frontend.py functions. Those functions will throw an exception if there > is a problem. As such your application can construct ufw command strings > to send to these frontend.py functions (these strings follow RULE SYNTAX > (see ufw(8)), and this syntax should not change in the future. > > TBH, I don't really have an interest in merging the ufw command and the > various frontends at this time. I envision the various frontends to be > autonomous, but absolutely want the API stable for you guys to use and > want to help in that regard. Whether or not you provide your own > graphical modules and/or combine the gtk/gnome/kde applications is of > course up to you. > > I also just had an idea for you guys (which would likely need to be in a the > aforementioned ufw-common package): create and use dbus for messaging so you > can take advantage of policykit. This will make it very friendly for Ubuntu > users, but likely less portable. I plan to look into dbus messaging more and > think about what it would take, but this would not be in a time-frame for > Jaunty. > > Jamie > > PS-- I'll also try to get a mailing list together so these things can be > out in the open. > _______________________________________________ Mailing list: https://launchpad.net/~gufw-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~gufw-developers More help : https://help.launchpad.net/ListHelp
