Meeting Notes -- 18 Jun 2003

What

• brown bag lunch -- Observable Queries

When & Where

• Wednesday 18 Jun 2003 -- 12:15 to 1:30
• OSAF office in Belmont

Who attended

• John -- JohnAnderson
• Jurgen -- JurgenBotz
• Pieter -- PieterHartsook
• Katie -- KatieCappsParlante
• Ducky -- DuckySherwood
• Brian -- BrianDouglasSkinner
• Aleks -- Aleksandar Totic
• Andi -- Andi Vajda

Agenda going in

• Walk through Brian's proposal for ObservableQueries
• Talk about different alternatives for keeping views in sync
• Free-form discussion

Highlights of what we talked about

• Intro questions
  1. "How do we make sure all views are in sync & showing current info?"
  2. "Should we set an architecture-level constraint on the number of open views?"
  3. "How long a delay is reasonable before a view shows current info?
     • seconds?
     • minutes?
     • when the user hits a "refresh" button?

• For question 2 above, we agreed that the question as stated isn't quite right. It's not really the number of open views that's important, but their relationship.
  • This update problem would be vastly simpler if we could always count on having some constrained set of views open at once, where all the views were hard-coded to work together to inform each other about changes (e.g. a view showing a list of e-mail messages and a view showing the selected message)
  • We resolved that we cannot assume that constraint. In general, the user will be free to open up a number of different views from different parcels, any of which might potentially be showing some of the same items.

• For question 3 above, there wasn't a clear answer
  • Mitch put in a quick vote for "seconds". Then we talked about different use cases -- calendaring vs. e-mail vs. other stuff. And we talked about the difference between updates within a client vs. updates from one machine to another. In some cases it seemed like instant update was important. In other cases it seemed like it might be fine to have a delay of a few minutes.
  • Pieter suggested that in some views it would be good to have a manual refresh button -- either in place of any automatic refresh, or in addition to an automatic refresh (in the case where the automatic refresh could have some delay that the user didn't want to wait for)
  • Katie suggested that we might want the parcel coder to decide how often it was important to have a refresh -- perhaps the refresh frequency could be set as an attribute of each query

• Brian emphasized that there are two different problems:
  • within a client, how does one view find out that a data item was changed by another view
  • on a network, how does one client find out that a data item was changed by another client

• Lots of discussion of the pros and cons of re-polling a remote machine vs. having the remote machine send messages about incremental changes

• Some discussion about what would be involved in having a server (or remote repository) have to keep track of what result sets it had already delivered in response to previous queries

• Ducky asked about the relationship between Observable Queries and data compositing
  • Brian said he hadn't ever thought about that and had no clue

• Ducky asked about whether it might be slow, pointing out that the query-checking step would be order N*log(M), where N is the number of registered queries, and M is the number of items in each query's result set. Brian agreed that it was order N*log(M), but asked what the alternative was -- Brian thinks any solution to the problem will be at least order N*log(M).

• Chao asked about pros and cons -- what likely pitfalls and upsides would be
  • Brian said:
    • One downside was that it would eat up memory (especially on a server, where one machine has to keep track of lots of outstanding queries)
    • As another downside, it would take some developer time to implement it
    • The upside is that once it's in place, hopefully automatic refreshes just work right, for the user and the parcel developer.
    • see also Jungle.ObservableQueries#Motivations

• John raised the point that there might be some queries that aren't "reversible"
  • forward vs. reverse
    • forward --> given a query, find the items that belong in the result set
    • reverse --> given a changed item, see if it belongs in a query's result set
  • simple vs. complicated
    • for a simple query, it should be possible to resolve the query in either a forward or reverse way -- an example of a simple query might be a calendar "month view" query, just asking for all the calendar events that fall between two dates
    • for a more complicated query, it might not be possible to resolve the query the reverse way -- an example of a non-reversible query might be something that involves arithmetic, or calculations, or derivations
  • the whole observable queries architecture assumes simple reversible queries, so if it turns out that Chandler also has complicated non-reversible queries, then we would need to make that distinction, and the observable queries framework could only be used for some queries
  • John suggests that it would be good to identify the different use cases that come up in Chandler, and figure out which might have simple solutions -- maybe use something like observable queries for the simple cases, without trying to undertake the research project of building a fully general solution

• We also talked about the relationship between observable queries and user-level notifications
  • Unclear just what the relationship is -- Brian suggested that maybe in many cases the things that a user wants to be notified about is just the fact that some result set changed -- if that's true, then maybe end-user notifications should be triggered by observable queries

Game plan coming out

• no follow-up tasks needed -- the goal today was just to present the ideas, get them on the table, and talk about them a little -- mission accomplished

-- BrianDouglasSkinner - 19 Jun 2003