On Tue, Jun 30, 2009 at 06:01, Eben Eliason<[email protected]> wrote: > On Mon, Jun 29, 2009 at 11:03 PM, Benjamin M. > Schwartz<[email protected]> wrote: >> Eben Eliason wrote: >>> On Mon, Jun 29, 2009 at 10:34 PM, Benjamin M. >>> Schwartz<[email protected]> wrote: >>>> Eben Eliason wrote: >>>>> I know GroupThink does everything it can to prevent collisions, but >>>>> with this we should also be thinking about the worst case. The >>>>> intended baseline behavior (before we get into any fancy merging >>>>> libraries) was to allow two instances with the same activity_id but >>>>> different version_ids to run simultaneously, and be joined by any of >>>>> their participants, thus allowing manual copy/paste merging. The >>>>> instance left open last would then become, naturally, the most recent >>>>> and therefore the "agreed upon" version moving forward. >>>> Hmm. This creates a bit of a dilemma. >>>> >>>> In Groupthink, there is no such thing as a collision. You could say >>>> "collisions are not supported". Therefore, my model has been that >>>> different versions of a document should always be launched into a single >>>> shared session, where the data will be merged immediately and >>>> automatically. If the user wishes to create a separate branch not to be >>>> automatically merged with the existing document, she should create a copy >>>> of the journal entry with a new activity_id. (No, we don't seem to have a >>>> UI for that.) >>> >>> The most basic UI for that, as I see it, is a "Keep a copy" secondary >>> item under the Keep button. >> >> Yep. This is what I expected the "Copy" option in the Journal to do, but >> that copies to the clipboard. Two options, "Copy to Clipboard" and "Copy >> this Entry" would be necessary >> >>> >>>> If the system is designed to prevent different versions from joining into >>>> a single shared session, then perhaps this explains the observed behavior. >>>> It also entirely prevents automerging of offline work. >>> >>> I don't think they're incompatible at all. >> >> I think we agree that they are incompatible as currently implemented, and >> that any implementation that permits this sort of automerging looks >> substantially different from what we have now, as you detail. > > Yup. > >>> Hence, perhaps some need for asking an open activity instance if it >>> can successfully "merge" (whatever that means to the activity) some >>> other object handle its given. If success is returned, the merge >>> happens; if failure is returned, the shell opens the requested >>> activity normally. >> >> I do not think an "object-based" merge system is best for this purpose. >> It seems to me that such a system would prevent any online "negotiation" >> between the two sides. Things get dramatically uglier if you consider >> joining a session containing many members, but not the initiator. Which >> user gets to decide whether the new one can join, when all users are equal? > > The leaderless merge issue doesn't seem any harder than the basic > leaderless collaboration issue. But I might be missing some obvious > complications. The short of it seems to be that the activity would > have to elect a given client to handle the merge. > >> It's not exactly a beautiful solution, but I'd prefer a toggle in >> activity.info: automerge=True/False. If automerge is False or >> unspecified, then we retain the current behavior (for the sake of > > And because the current behavior is the "correct" thing to do if merge > can't be automatic anyway! > >> compatibility). If automerge is True, then different versions are always >> combined into a single shared session. > > I'd carefully word this as "always attempted to be combined"... > >> To support "unreliable merge", we can use a self.unshare() method. If the >> local activity process, after negotiating with other group members, >> decides that merge is impossible, then it may leave the shared session >> shortly after joining and return to private scope. >> >> How does that sound? > > This sounds almost exactly like what I was suggesting, but in the > opposite direction. I was proposing to ask the activity on the fly if > it could perform a merge (this method would return false if > unimplemented), returning false when it wasn't possible (after > whatever negotiation was necessary...this method could be async). > You're suggesting to first check a global constant defined by the > activity to see if it will even try to merge at all, and a second > fallback method to be called (by the activity) in the case of a > failure. Actually, I guess if it's async, our two methods are > basically the same, except that you suggest the addition of the flag > in .info, which seems like a reasonable enough idea, though not > strictly necessary. > > In any case, both seem roughly equivalent in terms of experience, in > which case I don't really care. =)
Ben and Eben, do we have now a clear idea of where the problem lies and which API needs to be added to solve it? Thanks, Tomeu > Eben > > >> --Ben >> >> > _______________________________________________ > Sugar-devel mailing list > [email protected] > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
