Hi, On Tue, 2017-08-22 at 14:37 +0200, Pablo Neira Ayuso wrote: > On Mon, Aug 21, 2017 at 09:21:06PM +0200, Eric Leblond wrote: > > On Mon, 2017-08-21 at 11:44 +0200, Pablo Neira Ayuso wrote: > > > On Mon, Aug 21, 2017 at 11:06:19AM +0200, Eric Leblond wrote: > > [...] > > > In a nutshell: we provide a simple API for people that don't want > > > to > > > deal with IO at all, that's good. Then, an API that allows people > > > to > > > deal with IO themselves - advanced stuff. Simple API functions > > > would > > > be made of composites of the advance ones. > > > > OK, I'm good with this approach and it will please the "I'm afraid > > of > > netlink" club ;) > > OK, so we agree on the API policy then. > > [...] > > I think we can all have as a guideline for libnftables that all > > advanced things are going to the advanced functions. The simple > > functions must provide something appealing in term of features but > > have > > to remain really simple. > > Fine with it. > > > This make me think I still don't know how to deal with sets. I'm > > not > > planning to work on it but I think it is a feature that should be > > available in the simple functions. But we are dealing with possibly > > complex object so this can be really messy. > > What's your concern with sets? None fundamental really. It is just I don't see how we can build an easy API with set that can looks like "ipv4_addr . ipv4addr . inet_service". The use needs to be able to build the set object (could be a string) AND to parse it. This last part is the most complex I think. Maybe the JSON formatting could help here. ++ -- Eric Leblond <eric@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
