>> > 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 -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
