[Dev] Comments on Observable Queries Re: Dev digest, Vol 1 #186 - 1 msg

Brian Douglas Skinner skinner at osafoundation.org
Mon Sep 29 18:21:48 PDT 2003

Hey Andrew,

Thanks for reviewing the Observable Queries proposal!

Yes, I agree, the observer/observable model could be used for that 
scenario, provided there is an aggregate "Calendar model" that the view 
code can observe.  But I think in the Chandler world, there may not also 
be a one-to-one mapping between views and model objects.  The calendar 
views won't always be a window onto just the calendar model, but might 
also be used to show other types of items.  For example, Chandler might 
make it possible to use a calendar month view to show e-mail messages, 
organized by date received.  In general, any Chandler view just shows a 
collection of items, where that collection of items is the result of 
some query.  The only thing the items have in common is that they all 
got included in the query result set.  So generally speaking, there's no 
single model object that unites all the items, and there's nothing for 
the view to observe except the individual items, or the query itself.

But in the case where there is a calendar model object, the 
observer/observable pattern would work.  In a way, that 
observer/observable solution is similar to the Observable Queries 
solution.  Broadly speaking, both cases have the same general flow of 
events.  First there's some small change to a single appointment item, 
and that change leads to some simple notification, and that notification 
is noticed by some filter, and the filter decides that it cares about 
the change, and the filter notifies the view code.

The observer/observable solution and the Observable Queries solution 
mostly just differ in where the filtering is done.  In the Observable 
Queries solution, all the filtering is encapsulated in the query, and 
the view code only depends on the Query API.  Whereas in the 
observer/observable solution the filtering is split into two parts. 
First the Calendar model notices the change to the appointment item, and 
the calendar model applies a filter to decide that the appointment 
change constitutes a change to the calendar as a whole.  And then the 
view code gets notified that there's been some kind of change to the 
calendar model, and the view code then filters that info to decide if 
the change has any impact on the one day that it is displaying.  Or, 
alternatively, the view could punt on doing that filtering and instead 
just resubmit the query and redraw everything.

I like the Observable Queries pattern better, because it encapsulates 
the filtering chore, and keeps all the filtering out of the view code. 
If all the filtering is in the Query itself, behind the Query API, then 
it becomes an implementation detail as to whether the filtering is done 
on the client or done on the server.  And it becomes an implementation 
detail as to whether the Query even does filtering at all.  At one 
extreme, the Query could have filtering coded in some extremely clever 
optimized way, whereas at the other extreme there could be no filtering 
code at all, and the Query could simply do brute force periodic polling.


Andrew Francis wrote:
>>Brian Skinner is maintaining a Help Us! page on the
>>Chandler Wiki. This page is for small,
> self->contained, projects with clear deliverables 
>>which would help OSAF enormously. 
> I read the "Observable Queries Prototype" section
> and the beginning of the "Observable Queries" pages. 
> I have comments on the following scenario.
> BS>"Question: Let's say the user has two views, a 
> BS>Day View that shows Thursday, and a Week View 
> BS>that shows the whole week. Suppose the user, in 
> BS>Week View, drags a "Lunch" event from the Wednesday
> BS>column and drops it on the Thursday column. How 
> BS>does the separate Day View find out that it needs
> BS>to display the "Lunch" event?"
> BS>Answer: 
> BS>observer/observable: In scenario 1 we used a
> BS>simple "observer/observable" mechanism to register
> BS>interest in individual objects, but that won't 
> BS>work now. In scenario 2, the Day View has never
> BS>displayed the "Lunch" event before, and has never
> BS>registered as an observer, so it is never notified
> BS>of the edit. 
> I sketched out your example and I don't see why an
> observer/observable model could not handle the 
> aforementioned scenario. In the observer/observable
> model, I would suspect that the Week and Day View 
> would be registered to declare their interest in
> changes to the Calendar model's state.
> When an end-user drags a lunch event from Wednesday 
> to Thursday, this translates into the Calendar being
> updated and some type of update notification (event)
> being  generated and sent to the observers. The 
> update notification could either contain information
> about the state change, or can be a signal for the
> observers to fetch the appropriate Calendar state
> information. 
> In the case of the Day viewer, the viewer would 
> respond by grabbing information about Thursday events,
> (since that is what it is currently viewing) and 
> would consequently display the new Lunch event. If
> the viewer was smarter, it may check the Calendar
> against its internal representation to see if things
> have indeed changed.......
> Cheers,
> Andrew

More information about the Dev mailing list