On Mon, Mar 15, 2010 at 10:34 AM, David Leimbach <leim...@gmail.com> wrote: > I don't know enough about sam's innards to be able to say whether or not > this could work, but I do like the idea.
I think it's doable because of the way sam's remote mode works -- it appears to just use pipes. Therefore, I thought that maybe a multiplexer could sit between a single sam and several samterms, organizing the protocol messages from all the different samterms and presenting something sane to the single sam -R instance. It would have to be convincing to that individual sam, appearing to be a single `normal' samterm. I think the fact that sam uses a database-like protocol would make that possible; all the results of the multiplexer's merging and so forth would be presented to the sam -R instance as if they were coming in as protocol messages from a single samterm. > > On Mon, Mar 15, 2010 at 7:05 AM, Jorden Mauro <jrm8...@gmail.com> wrote: >> >> How hard would it be to stick a program between a single sam -R and >> several samterms? I imagine such a program would have to interpret the >> sam protocol and handle merges and simultaneous updates, but since sam >> essentially treats files operations as database transactions, it seems >> like sam's protocol could be very helpful. The possibilities for what >> such an intermediary program could do are probably limitless, but I >> was thinking it could make collaborative editing via sam a >> possibility. >> >> I don't know enough about sam's protocol to know if such an idea would >> work. >> > >
