When resuming object in different activity, old activity id is reused

[bert]

Take a photo in record. Note activity id. Close record. Resume photo in Browse (or another activity). It gets the same activity id.

In one case this lead to an activity startup error (dbus name could not be aquired), apparently the dbus service fro record was not released yet and the next activity tried to register the same service (because it got the same instance id).

[tomeu]

Eben, what should happen in this case?

If the resumed object has a different bundle_id, should we launch this object with a new activity_id? Or should we duplicate it also with a new activity_id?

[Eben]

Well, I think I need a little more clarification on the bits that back this system up. In a sense, we need 3 separate identifiers. The first identifies the kind of object (akin to a type code; I assume we just use MIME). The second identifies an associated activity (akin to a creator code; I have no idea how we handle this). The last is what's been known as the activity_id, which tracks the shared collaboration around a given object/activity (which has no mapping to current systems).

I think the confusion here lies somewhere between the activity association and the activity_id, which I think are distinct entities. In fact, it might be clearer to adjust the terminology and call it a collaboration_id instead, to detach it from any single Activity: it refers to an activity in the general sense, rather than to the chunk of code which defines a single Activity on the laptop, the semantics of which aren't very clear.

Using these new collaboration semantics, it would be clear that a collaboration can continue on a painting, regardless of what Activity the children use to work on it. Marco, Tomeu, how does this match what's currently under the hood? (For the record, I believe the reason collaboration_id wasn't chosen in the past was because it implies that an activity is shared. This isn't the case, so we have to accept the notion of a single-child collaboration -- or the potential for future collaboration -- when using this terminology.)

[marco]

As discussed in irc collaboration_id is not quite what we want here.

Eben suggested to make a copy of the journal entry when opening it with another activity. It would certainly solve a lot of problems, but it would slow down things and waste space, especially for big files.

I'm not sure what's the best compromise until we have versioning. And I'd be pretty nervous to put the "copy on open with" change in Update.1.

[bert]

Replying to marco:

I'm not sure what's the best compromise until we have versioning.

Pretty simple: leave it to the activity. Do not touch the journal entry, no duplicate etc. Simply launch a fresh activity with a new activity_id, but pass the object_id. Passing an activity_id that belongs to a different bundle into another activity is simply wrong.

[bert]

Btw, looking at #6253 makes it obvious why we need a new instance (and hence, activity_id).

[tomeu]

If an activity is already running with the that activity_id, then we can switch to it if the bundle_id is the same. If not, we will need to copy the entry as the same entry cannot be edited at the same time. See #6253.

If no activity is running with that activity_id, then copying would make sense from the user POV, other than if the associated data is big (video, audio, etc) then we'll wait for it to copy and will take a lot of extra space.

The only viewers that we have for those heavy types are Browse (with the totem plugin), Etoys and Watch & Listen.

What if we modify these activities to not touch the journal entries that they open for read-only?

[bert]

Replying to tomeu:

What if we modify these activities to not touch the journal entries that they open for read-only?

That's what Etoys does now (see #5348).