Juha Heinanen wrote:
i'll send you the diffs privately first and if you think they are ok for general consumption (perhaps after adding peer class into the db tables), i can commit them to cvs.
As far as I can see, it's basically the same concept as for load_gws()/next_gw() and from_gw() with some additional checks for incoming requests, isn't it? The thing I'm missing here for my usage is the fail-over handling (serial forking) to another outgoing peer. In many situations it's also not handy to split up incoming and outgoing peers into separate tables (administration overhead). But as you have pointed out, it's made to fit your own needs.
Some thoughts on the performance issue of the DB query regarding my patch which extends the functionality of load_gws(), from_gw() and to_gw():
- there's no performance impact in from_gw() and to_gw() - if no group id is passed to load_gws() , the query stays the same, thus also no performance impact - grp_id is filtered first in the query if passed to load_gws(), so the join of lcr and gw tables should speed up (I'm not a DB specialist though, just an assumption, correct me if I'm wrong) - if one has performance issues with non-cached load_gws(), he maybe should consider using caching anyway.
Andy