* [9fans] Collaborative Sam? @ 2010-03-15 14:05 Jorden Mauro 2010-03-15 14:34 ` David Leimbach 2010-03-15 22:23 ` Skip Tavakkolian 0 siblings, 2 replies; 9+ messages in thread From: Jorden Mauro @ 2010-03-15 14:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] Collaborative Sam? 2010-03-15 14:05 [9fans] Collaborative Sam? Jorden Mauro @ 2010-03-15 14:34 ` David Leimbach 2010-03-15 15:14 ` Jorden Mauro 2010-03-15 22:23 ` Skip Tavakkolian 1 sibling, 1 reply; 9+ messages in thread From: David Leimbach @ 2010-03-15 14:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 801 bytes --] 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. On Mon, Mar 15, 2010 at 7:05 AM, Jorden Mauro <jrm8005@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. > > [-- Attachment #2: Type: text/html, Size: 1065 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] Collaborative Sam? 2010-03-15 14:34 ` David Leimbach @ 2010-03-15 15:14 ` Jorden Mauro 2010-03-15 15:30 ` David Leimbach 0 siblings, 1 reply; 9+ messages in thread From: Jorden Mauro @ 2010-03-15 15:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Mar 15, 2010 at 10:34 AM, David Leimbach <leimy2k@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 <jrm8005@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. >> > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] Collaborative Sam? 2010-03-15 15:14 ` Jorden Mauro @ 2010-03-15 15:30 ` David Leimbach 2010-03-15 17:04 ` Chad Brown 2010-03-15 17:47 ` Jorden Mauro 0 siblings, 2 replies; 9+ messages in thread From: David Leimbach @ 2010-03-15 15:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 2303 bytes --] On Mon, Mar 15, 2010 at 8:14 AM, Jorden Mauro <jrm8005@gmail.com> wrote: > On Mon, Mar 15, 2010 at 10:34 AM, David Leimbach <leimy2k@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. > > Well I think there'd have to be a concept of a session in there somewhere, so that edits by one person could be differentiated from edits by another. Also how atomic are the messages in the protocol and can they be "committed" transactionally to the buffer? If so I think there might be something doable here. It'd be cool to use with Inferno for example, where you can run editing sessions from anyone's PC in a company setting. Isn't that what the collaborative whiteboard app in Inferno is/was for? I've never tried running it. Dave > > > > On Mon, Mar 15, 2010 at 7:05 AM, Jorden Mauro <jrm8005@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. > >> > > > > > > [-- Attachment #2: Type: text/html, Size: 3166 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] Collaborative Sam? 2010-03-15 15:30 ` David Leimbach @ 2010-03-15 17:04 ` Chad Brown 2010-03-15 17:38 ` Jorden Mauro 2010-03-15 17:47 ` Jorden Mauro 1 sibling, 1 reply; 9+ messages in thread From: Chad Brown @ 2010-03-15 17:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Have you read ``The Text Editor Sam'', by Rob Pike? (http://doc.cat-v.org/plan_9/4th_edition/papers/sam/) A quick re-skim (especially around page 22) or so suggests that you'd want to look at the code for sam -r, and that you'll want to dig into the Rasp data structure, but (contrary to my memory), it might be possible without breaking the existing protocol. Good luck! *Chad ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] Collaborative Sam? 2010-03-15 17:04 ` Chad Brown @ 2010-03-15 17:38 ` Jorden Mauro 0 siblings, 0 replies; 9+ messages in thread From: Jorden Mauro @ 2010-03-15 17:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Mar 15, 2010 at 1:04 PM, Chad Brown <yandros@mit.edu> wrote: > Have you read ``The Text Editor Sam'', by Rob Pike? (http://doc.cat-v.org/plan_9/4th_edition/papers/sam/) > > A quick re-skim (especially around page 22) or so suggests that you'd want to look at the code for sam -r, and that you'll want to dig into the Rasp data structure, but (contrary to my memory), it might be possible without breaking the existing protocol. > > Good luck! > *Chad > Yes this is a start, but I feel a bit out of my league still after reading the paper and some of the code a few times; I just learned enough about it to think it's possible. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] Collaborative Sam? 2010-03-15 15:30 ` David Leimbach 2010-03-15 17:04 ` Chad Brown @ 2010-03-15 17:47 ` Jorden Mauro 1 sibling, 0 replies; 9+ messages in thread From: Jorden Mauro @ 2010-03-15 17:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Mar 15, 2010 at 11:30 AM, David Leimbach <leimy2k@gmail.com> wrote: > > > On Mon, Mar 15, 2010 at 8:14 AM, Jorden Mauro <jrm8005@gmail.com> wrote: >> >> On Mon, Mar 15, 2010 at 10:34 AM, David Leimbach <leimy2k@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. >> > > Well I think there'd have to be a concept of a session in there somewhere, > so that edits by one person could be differentiated from edits by another. > Also how atomic are the messages in the protocol and can they be > "committed" transactionally to the buffer? If so I think there might be > something doable here. I would think that the multiplexer would handle all of this. It could just check what time the samterms' messages come to it, resolve them, and output a single stream of sam protocol messages to the single sam -R on the server side. Of course, there's more to this `handling' than there seems at first glance, but as long as the multiplexer can handle all the client samterms' messages, merge everything properly, and once it makes sense of all the requests, emit a single stream of sane samterm messages to the sam -R that it talks to on the server-side, I think it would work. The only modification to sam would be adding the option to set up the pipes on both ends and fork the multiplexer -- which would read pretty much the same as the connectto() functionn /sys/src/cmd/sam/io.c . > It'd be cool to use with Inferno for example, where you can run editing > sessions from anyone's PC in a company setting. > Isn't that what the collaborative whiteboard app in Inferno is/was for? > I've never tried running it. > Dave > >> >> > >> > On Mon, Mar 15, 2010 at 7:05 AM, Jorden Mauro <jrm8005@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. >> >> >> > >> > >> > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] Collaborative Sam? 2010-03-15 14:05 [9fans] Collaborative Sam? Jorden Mauro 2010-03-15 14:34 ` David Leimbach @ 2010-03-15 22:23 ` Skip Tavakkolian 2010-03-15 23:14 ` Jorden Mauro 1 sibling, 1 reply; 9+ messages in thread From: Skip Tavakkolian @ 2010-03-15 22:23 UTC (permalink / raw) To: 9fans if you carry the idea through, i think you'll reinvent 9p and mount :) > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [9fans] Collaborative Sam? 2010-03-15 22:23 ` Skip Tavakkolian @ 2010-03-15 23:14 ` Jorden Mauro 0 siblings, 0 replies; 9+ messages in thread From: Jorden Mauro @ 2010-03-15 23:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mon, Mar 15, 2010 at 6:23 PM, Skip Tavakkolian <9nut@9netics.com> wrote: > if you carry the idea through, i think you'll reinvent > 9p and mount :) Of course, the idea could be done as a 9p file server. However, I think the fact that sam already uses a protocol with database-like semantics would greatly reduce the work needed. I also don't think that such a scheme would allow for real-time update in samterm (though of course, I don't know if my original idea would, either!) > >> 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. > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-03-15 23:14 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-03-15 14:05 [9fans] Collaborative Sam? Jorden Mauro 2010-03-15 14:34 ` David Leimbach 2010-03-15 15:14 ` Jorden Mauro 2010-03-15 15:30 ` David Leimbach 2010-03-15 17:04 ` Chad Brown 2010-03-15 17:38 ` Jorden Mauro 2010-03-15 17:47 ` Jorden Mauro 2010-03-15 22:23 ` Skip Tavakkolian 2010-03-15 23:14 ` Jorden Mauro
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).