Opened 9 years ago

Last modified 9 years ago

#6254 new defect

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

Reported by: bert Owned by: tomeu
Priority: high Milestone: 9.1.0-cancelled
Component: journal-activity Version: Development build as of this date
Keywords: 9.1.0:+ Cc: Eben, marco, tomeu, mstone
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no


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).

Change History (9)

comment:1 Changed 9 years ago by tomeu

  • Cc Eben added

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?

comment:2 Changed 9 years ago by Eben

  • Cc marco tomeu added

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.)

comment:3 follow-up: Changed 9 years ago by 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.

comment:4 in reply to: ↑ 3 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by bert

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

comment:6 follow-up: Changed 9 years ago by 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?

comment:7 in reply to: ↑ 6 Changed 9 years ago by 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).

comment:8 Changed 9 years ago by mstone

  • Cc mstone added

comment:9 Changed 9 years ago by tomeu

  • Keywords 9.1.0:+ added; Update.1? removed
  • Milestone changed from Never Assigned to 9.1.0
Note: See TracTickets for help on using tickets.