p2p developer events [was: Invite from Robert Stehwien]
siguctua at gmail.com
Fri Sep 7 09:25:15 UTC 2007
On 07/09/07, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
> On Fri, 07 Sep 2007 10:24:16 +0200, Igor Stasenko wrote:
> > On 07/09/07, G"oran Krampe <goran at krampe.se> wrote:
> >> Hi Robert!
> >> > I would like to apologize for this. Don't sign up whatever you do.
> >> I admit my first thought was "How stupid is that guy?"... ;)
> >> But welcome to the Squeak community! :)
> >> And oh, btw, I noticed you are (still?) fishing for a thesis, here is
> >> one
> >> idea:
> >> Implement the idea of "publish/subscribe model of developer events"
> >> using
> >> p2p and investigate how it changes the interaction patterns within an
> >> open
> >> source community.
> >> This would cover p2p, collaboration and possibly also visual
> >> programming.
> >> It also does not really exist so the effects on a community would be
> >> "something new" to dissect. On the other hand it also slightly depends
> >> on
> >> you being successful in implementing it and getting users.
> >> The base idea is to add a publish subscribe model more or less on top of
> >> SystemChangeNotifier (which broadcasts events for every source code
> >> change
> >> you do) and then let each developer decide what to broadcast and what to
> >> subscribe to (globally).
> >> Then you can turn these events into visual cues in the development
> >> tools -
> >> like "2 other people on the globe has modified this class during the
> >> last
> >> hour" or "this class is being browsed by 5 other people right now" etc.
> >> Endless possibilities of near real time collaboration! :)
> > Ohh, that is very very ambitious :)
> > And this covers very wide range of problems/options.
> Interesting comment :) BTW would it require more/other concepts than those
> described in
> - http://www.ietf.org/rfc/rfc977.txt
> I'm interested to learning what concepts would need to be addressed beyond
> those in RFC 977 so, if you know/think about some please post. TIA.
1.2. The USENET News System
Clearly, a worthwhile reduction of the amount of these resources used
can be achieved if articles are stored in a central database on the
receiving host instead of in each subscriber's mailbox. The USENET
news system provides a method of doing just this. There is a central
repository of the news articles in one place (customarily a spool
directory of some sort), and a set of programs that allow a
subscriber to select those items he wishes to read. Indexing,
cross-referencing, and expiration of aged messages are also provided.
As you may know p2p networks designed in such way, that they don't
require any kind of central repository (as news server in USENET).
In p2p networks you always talking with peer, and sending
events/messages directly to them not to some central storage.
The only tiny thing which p2p may require at start-up is a list of
well known peers, which can be provided by a user, or downloaded from
server which keeps track of them. Or in any other way you can provide.
> > I think it will be very sensitive from initial design. Its relatively
> > easy to establish a p2p network which will exchange events/messages.
> > The questions is, what would be the messages payload, what kinds
> > should be supported and etc etc.
> >> regards, Göran
Igor Stasenko AKA sig.
More information about the Squeak-dev