So, yesterday we were discussing the possibility of moving the Mugshot client to use the data model rather than custom notification; a lot of the information that the Mugshot client uses fits well into the data model ... information about users, groups, even each individual stacker block. But there are two things that fit less well: - The stack itself - The contents of a chat room In both of these cases, just using a list-valued property wouldn't work well ... we never want *all* the blocks in your stack or *all* the messages in the chatroom, just the more recent entries. The question that comes to mind then is: are these two special cases in a world of things that can't be handled well by the data model? Or is there some simple addition to the data model that would handle both of these cases and lots more similar things besides. What I think the two things above are is "feeds". Property of a feed: - The feed is ordered - Items are typically added at or near the end of the feed - The basic access operation is "give me N items from the end of the feed" - The complete set of items in the feed is potentially very large Feeds are very familiar concepts via RSS and Atom these days. Along with the two examples above, we can come up with many more ... from email inboxes to upcoming concerts. Anything, in fact, that an RSS feed is used for these days. The Mugshot stack extends the feed concept a bit with the concept of "restacking" - An item in the feed can be removed from the feed and reinserted at or near the end of the feed. This sort of idea comes up elsewhere; for example in a threaded or conversation view of an email inbox, a thread can be moved to the end when new messages arrive in that thread. More concretely, I'm thinking that in a data model, a property that that is feed-valued would have values that are pairs of resources and timestamps. (So, I've specialized the abstract concept above a bit to say that the ordering of a feed is by timestamp, and the "end" of a feed is the most recent items.) So: <group xmlns="http://mugshot.org/p/o/group";> <chatMessages m:type="f*" m:resource="/o/chatMessage/513423" m:ts="1193931374313"/> <chatMessages m:type="f*" m:resource="/o/chatMessage/513426" m:ts="1193932521431"/> ... </group> Fetch strings are already specified to allow "chatMessages(max=50) +", the ordering defined for a feed gives an exact definition of what that maximum means. A feed valued property would also have a default maximum if one wasn't specified explicitly in the fetch string. I haven't yet completely figured out how feeds look like on the server side. Basically, I think you'd specify a property: @DMProperty(defaultMaxFetch=25) Feed<ChatMessageDMO> getChatMessages(int start, int max) And that returns a Feed custom container object that contains *at least* (but not necessarily only) the feed item items given in the range. It might be useful to extend ReadWriteSession.changed() to allow saying not just "chatMessages changed", but to give details of the change, so we can avoid having to requery past messages and do a diff. That would take some care to make sure that it was safe with respect to concurrency, transactions, and threading. - Owen
Attachment:
signature.asc
Description: This is a digitally signed message part