Hi Igor,

got the point :)

And now, every p2p developer events participant rushes out for buying a  
really reliable backup service/equipment, just in case the contributions  
she/he made three years ago where never replicated to somebody else (or  
where "lost" by everybody else as well).

How's history addressed in such scenarios (except DIY/DeverythingY), any  
experience/good practice? TIA.

/Klaus

On Fri, 07 Sep 2007 11:25:15 +0200, Igor Stasenko wrote:

> 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.
>
>> /Klaus
>>
>> > 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
>> >>
>