gufw-developers team mailing list archive

[Marcos Alvarez Costales <marcos.alvarez.costales@xxxxxxxxx>]

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.
>