-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm wanting to start on some functions to automatically populate
sl_listen entries.

The thought has been to do this based on what happens when subscriptions
are requested; when a subscription is added, we'd obviously be able to
replace existing sl_listen entries with ones based on latest conditions.

This involves hooking into existing functions.  It looks tempting to
this support in in several places, and I'd be grateful to hear about any
"green lights" or self-evident pitfalls.

1.  enablenode(node_id)

~    Should be able to set up that _everyone_ likes to listen to 'this
~    node' for events if they don't already have a data source.

~    Or perhaps this is unnecessary; instrumenting
~    moveset()/subscribeset()/unsubscribeset() may suffice

2.  moveset(id, old, new)

~    Anyone listening to the old node should listen to the new node

3.  subscribeset(id, provider, receiver, forward)

~    Anyone listening to provider should go through receiver

4.  unsubscribeset(set, receiver)

~    Anyone listening to the receiver should go to the former provider

5.  storenode(node, description)

~    I'd like to do nothing; if a node hasn't been pointed to by
~    anything, it oughtn't matter if it isn't communicating with
~    other nodes, right?

Am I right about #5 (storenode())?  Or should I arbitrarily set up some
sl_listen entries when the node is created?

I think it ought to suffice to instrument the three set operators
moveset(), subscribeset(), and unsubscribeset(), and perhaps
enablenode().  Or is there a conspicuous case where that breaks the network?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBiBB7CVn6LJfHIAIRAvB1AJ4wu3nthwMtccWeSzffP6YYBlE38gCgz28X
Y1JKNM0woAIPeLHmPTOYKe8=
=HQjX
-----END PGP SIGNATURE-----