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