Hi List,<div><br></div><div>Random thoughts on Duncan post:</div><div> - It seems to me some (a lot?) of these requirements are implemented in p2p protocols like bittorrent. Couldn't this be the basis of a test?</div><div>
- Not sure the "elected proxy" model would be more efficient than peer discovery in bittorrent (although it's just an idea, I must have a more detailed look into bittorrent), but it could include other goals than network efficiency in the election process</div>
<div> - It would be interesting to prototype this system as a kind of connection or messaging infrastructure layer on which several messaging protocol could be implemented</div><div> - While thinking about the same issues, I came with a different idea than election, some peers could declare they offer "relaying" (don't know how to call it) services and each peer could decide if it wants to use it. Of course, this is a kind of election process, but there is no communication between voters, but a swaming behavior.</div>
<div><br></div><div>On the last point, I discovered ULS while experimenting with a software architecture concept, on a very small scale, but with a lot of similar ideas. I'm trying to write down some of these ideas on a blog <a href="http://msa-blog.adrahon.org/">http://msa-blog.adrahon.org/</a> (warning: handwaving heavy). I'm using Zeroconf for service publication and discovery, and I'm trying to design a small language that services (or nodes) could use to declare the capability they provide, some of which could be messaging/discovery related (I'm a proxy, I'm a local service registery, I can talk to...).<br>
<br></div><div>Will I sound very naive and ignorant if I say that defining each layer's responsibility is awfully complex?</div><div><br><div class="gmail_quote">On Sat, Sep 19, 2009 at 4:18 AM, Duncan M. McGreggor <span dir="ltr"><<a href="mailto:duncan.mcgreggor@gmail.com">duncan.mcgreggor@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Ideally, what I'd like to see (this may be different than what Jamu<br>
thinks -- I'll let him respond with his own views on this!) is a<br>
messaging solution:<br>
<br>
* that would allow applications to auto-discover peers<br>
<br>
* where a collection of nodes would segment into groups and elect a<br>
peer to act as their communication proxy to managing or reporting<br>
entities for that segmented group of nodes<br>
<br>
* where the elected proxy would perform actions such as forwarding<br>
messages or holding messages in a queue<br>
<br>
* that has the flexibility to re-form node groupings and re-elect a<br>
proxy based on various conditions<br>
<br>
Ideally, this would be a protocol-level messaging solution, allowing<br>
developers to implement clients, servers, and applications as-needed.<br>
Our first thought was Twisted + AMP as a starting point. But having<br>
taken the time to write this down, it's sounding an awful lot like half<br>
of this is going to be a full-blown messaging/routing protocol.<br>
<br>
This may end up being the case, but it would be a lot of fun just to<br>
start hacking on some proof-of-concept, prototype stuff ;-) (i.e.,<br>
exploration and investigation, not a committee-driven effort) Sound<br>
like fun to anyone else?<br>
<br>
If anyone is interested or has input, thoughts, experience to share,<br>
feel free to chime in!<br>
<br>
Thanks,<br>
<br>
d<br>
_______________________________________________<br>
ULS-SIG mailing list<br>
<a href="mailto:ULS-SIG@python.org">ULS-SIG@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/uls-sig" target="_blank">http://mail.python.org/mailman/listinfo/uls-sig</a><br>
</blockquote></div><br></div>