Everything a Scooby Engineer Would Want to Know About the Chandler Domain Model (That Alec Didn't Cover Already When He Led the Session About Collections) but Was Too Afraid To Ask.

What Alec did cover: CollectionMeeting20060512

Drawrings: Grants_Stamping_Talk.pdf: Grants_Stamping_Talk.pdf

Some reading:

• The Chandler 0.7 stamping spec has a good backgrounder on the motivation for stamping in the section “Explanations for Stamping”.
• A high-level FAQ-type journal entry: LisaDusseault20040614 (a follow-up to LisaDusseault20040611).
• Mixins vs annotations:
  • http://lists.osafoundation.org/pipermail/chandler-dev/2006-May/005882.html
  • http://lists.osafoundation.org/pipermail/design/2005-January/003068.html
  • Design POV on that discussion: StampingRevisited

Agenda

• Announcement of the working title (2 mins*)

• Stamping:
  • Theory (5 mins)
  • The current implementation (10 mins)
  • 0.7 plan (10 min)

• @-time & Anytime Events (5 mins)

• User-Defined Attributes: (5 mins)

Notes

• What stamping isn't
• What stamping is
  • single item that can have multiple different kinds
  • simultaneously task and email
  • email: "hi! I'm having a potluck at a given date/time". Instead of copying and pasting entire email into calendar, just stamp the original email as an event, it retains its original emailness, and one has cut out a whole bunch of steps.

• What is the planned implementation, what are the problems we've run into and what we are planning on doing?
  • We still have to check that the plan will solve the laundry list of problems

• 0.4 implementation
  • modelled using multiple inheritance in python
  • mixin classes in python
  • there is a parallel universe of kinds/attributes/items
  • you can change the class of an item instance on the fly

• 0.4 problems
  • pattern of mixins was tricky to figure out on the fly
  • concrete class inherited from the mixin as well as content item, tricky for developers creating new stamps
  • possible to have overlapping attributes: subject of email is kind of the same as title of a task
  • a bit murkier because you can unstamp an item as well, you lose values (class is pulled out of object class hierarchy -- all records of that go away -- orphaned values are removed)
  • How do you deal with overlapping?
    • redirectto mechanism lets you link to an attribute -- any attribute has a "what" attribute that links either to subject, title, etc. Problem here, kinda wacky when you unstamped. We used to try and preserve attributes when you unstamped, but that caused problems with queries against the repository, we'd find the orphan attributes. Unstamping may come back with some other solution to the problem.

• Attribute redirection (not necessarily directly a stamping topic)
  • columns in a table: who, when, about
  • we'd use redirection to choose what showed up in "who" column for different types (when --> start time for event, when --> sent for email)
  • not really flexible enough, "from" emails and "to" emails really want to display different attributes
  • idea of context: the same thing needs to be displayed differently in different contexts in the ui, can't we model that in a better way

• Annotations
  • eventually these persist in the repository, but really are a higher level concept
  • flexible way of adding attributes to items in the repository
  • you can think of them as bags of attributes and methods
  • the newly added attributes are in their own namespace

• What was the problem that annotations solve?
  • extensibility and separation of code
  • core event class has ical uuid, really it has nothing to do with eventness
  • if we moved it to an annotation, it becomes part of the sharing code
  • could we use it for parcel development? Yes, Exactly. Photos you want to turn into flicker photos.
  • Annotations: I need to add behavior and data storage to some type, without adding to chandler core.

• Proposal moving forward for stamping, use annotations instead of mixin types
  • Each stamp has attributes and methods
  • Ask the item what stamps it currently has
  • Be able to ask for all events in a collection
  • Calendar view would be associated with the "event" stamp
  • Long discussions on chandlerdev and back way earlier ("hasa" approach vs "isa" approach)

• How do annotations solve the problem of sorting the "who" attribute?
  • will the attribute name be constant? this is needed for indexing/sorting
  • we still have the opposite side of the "who" column
    • two mixins will collide now, that is bad
    • we lose the "who" arbitrary redirection

• We're using some python trickery to cheat -- member variable names are fully qualified names
  • in python you can't directly have an attribute name with dots in it -- apis exist to look up attributes dynamically
  • like a similar cheat in javascript (matt describes a trick)

• @time and anytime events -- scooby deals with it, custom ical thing

• user defined attributes
  • simplest example: tags -- name/value pair without a value
  • will implement using some kind of annotations

• AttributeManager
  • big picture grand vision for user defined attributes
  • Andi: perhaps user defined attributes should be references to other items, some advantages w/bidirectional references
  • For every user defined attribute, you can think of there being a collection
  • What is the relationship between domain model and collections?
    • Andi: two types of collections -- collections of bidirectional references
    • computed collections -- queries that build them, we talk about them as collections
    • not materialized until you iterate/index them
    • What about collection that is a specific group of items? a building block
    • Ted: from the point of view of what the developer gets, the API is pretty close to the same, conceptually the same but implemented different ways