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&#39;t this be the basis of a test?</div><div>
 - Not sure the &quot;elected proxy&quot; model would be more efficient than peer discovery in bittorrent (although it&#39;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 &quot;relaying&quot; (don&#39;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&#39;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&#39;m using Zeroconf for service publication and discovery, and I&#39;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&#39;m a proxy, I&#39;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&#39;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">&lt;<a href="mailto:duncan.mcgreggor@gmail.com">duncan.mcgreggor@gmail.com</a>&gt;</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&#39;d like to see (this may be different than what Jamu<br>
thinks -- I&#39;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&#39;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>