Process question. All of these things will eventually need to be a
spec. Is this something Morgen / Sheila and I should work on
together? Track proposals...document designs.
On Jul 31, 2006, at 4:36 PM, Jeffrey Harris wrote:
How does this sound:
EmailAddress is a separate item from a contact. When I share an event
with you, I let you know the UUIDs for any EmailAddresses in the to:
field. In this case lets say the EmailAddress is for PinkFlamingo, a
contact you already have. When you receive the item, your Chandler
would note the UUID my EmailAddress used in your version of
PinkFlamingo
or PinkFlamingo's EmailAddress (probably creating a stub item with
that
UUID).
If later I share my version of PinkFlamingo with you, the fact that a
stub item with the same UUID already exists would trigger merge
UI. You
would have the opportunity to merge your existing PinkFlamingo with
mine, possibly keeping some of your original attributes as private
annotations that you don't share back to me. You also store a history
of the fact that these PinkFlamingos (both the Contact items and the
EmailAddress items) have been merged, so if you were sharing
PinkFlamingo with someone else and you share the new version with
them,
they'd get their own independent chance to merge PinkFlamingos.
If you chose not to merge PinkFlamingos, we could provide alternate
behavior where you would maintain a (perhaps private) link between the
two, and designate which contact should be used by default when
lists of
contacts are constructed.
This would certainly be the ideal solution. What's a good way to
phase this? Store the UUID for now...but defer the reconciliation
functionality until later.
*3. Rationalizing import items with versions of the same items
received via Sharing*
+ A exports a collection and emails the collection to B
+ B imports the collection at which point, B can start to make
changes to items in the collection
+ A then decides to share the collection with B
What happens?
+ When A exported the collection and emailed it to B, what was the
motivation / expectation?
- Most likely, it was not: Keep my collection and B's version of the
collection in sync
- More likely, it was: I'm making a copy of my collection for B, now
B can do whatever they want with it
+ As a result, export, should really be: Export a copy
Q. Is this going to screw up scenarios where A is exporting items in
order to back them up for himself? What if A loses part of his
repository and then decides to re-import the back-up and ends up with
a bunch of dupes?
+ Maybe we need both Export and Export copy; OR Backup and Export
copy.
I think when we do an export, we might consider copying (i.e.,
creating
new UUIDs for our items), but maintaining back-links to the original
items in the copy. So if the recipient of the copy ever comes across
the original in sharing, they have the option of merging their copy
(and
any changes they've made) into the original item, but they don't
have to.
Oooh, nice. I was thinking that it was really on the re-import end
where you want to make this kind of decision.
In this architecture, we could have a special restore-from-export
option
that would get back the original UUIDs, we wouldn't need backup and
export actions.
How realistic is this in Beta? Sorry to be a broken record.
Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
