> > Hi,
> <snip>
> > In both cases we would ideally like the application developers to take some
> > action in terms of how they deal with the situation.
>
> There wasn't any usable APIs for applications when I first replied to this
> thread, and there still isn't any.
>
> Man "firewalld.dbus" will show you what app developers are supposed to
work
> with.
Well since the whole context of the discussion was that we can not expect developers to
specifically code for firewall.d, I did not of course propose the do this using
the firewall.d API. Transmission for instance includes functionality for testing if
the port it wants to use is available (and I assume it is not doing that using the
firewall.d API).
Of course I don't know if what Transmission does is done using 'non usable'
APIs
according to your definition.
> > That said to me the request we would make of them in the firewall scenario
> > seems easier to do generically than the option we would
> > like them to take in the second option, and also less of a risk when some
> > of
> > the app devs will not do what we hope they
> > will.
>
> Certainly, because users will simply disable the firewall and be done with
> it.
> That's certainly what I do.
Well I guess you find a lot more value in sharing your photos over DLNA in the local
internet cafe than most of us then :). Personally if my DLNA sharing silently failed
due to me having chosen the internet cafe to be an untrusted area I would likely never
realize as it is not a usecase I have ever cared about.
Ultimately someone should probably integrate the use of the UPNP IGD
standard better into firewalld, we already have gupnp-igd, so that it
can poke firewalld to open up ports dynamically. DLNA is on top of
UPNP so there's technologies there that should work and it would nice
to be able to have IGD support for firewalld in both a separate
firewall/router device and on on local firewalld instances so that
when two UPNP devices are communicating they can dynamically open up
ports on demand.
Peter