[Chandler-dev] What is next for Chandler desktop?

[Phillip J. Eby]

At 06:25 PM 9/5/2007 -0700, D John Anderson wrote:
>On Sep 5, 2007, at 5:03 PM, Grant Baillie wrote:
>>On 5 Sep, 2007, at 14:47, D John Anderson wrote:
>>>On Sep 5, 2007, at 2:05 PM, Katie Capps Parlante wrote:
>>>>- Perhaps we shouldn't be storing UI items in the repository. Yes,
>>>>transparently persisting UI state is in theory a cool property,
>>>>but in
>>>>practice I don't know that we are effectively getting the
>>>>persistence
>>>>right and it perhaps comes at too great a cost.
>>>
>>>Are you proposing that we don't use transparent persistence for
>>>storing blocks and other associated UI data structures?
>>
>>Yes, that is the suggestion/proposal.
>
>It seems to me that the transparent persistence isn't a problem but a
>feature because it makes the code so much easier to write and much
>less error prone.
>
>Having worked on lots of projects that required I do a SQL queries
>every time I need to access some data convince me that it slows
>progress. I suspect a better solution would be to keep a mostly
>transparent persistence model but change the data storage and/or data
>structure underneath it to avoid requiring the programmer to manage
>the data access manually.

Right, we need to distinguish between access transparency and schema 
transparency.  Access transparency is a good thing.

On the other hand, it's pretty well established at this point that 
schema transparency tends to run counter to our goals at certain 
points; we use EIM for sharing and dump/reload specifically to 
*break* schema transparency, because it's better for us to have an 
explicit delineation between internal objects and external schemas.

In the context of the UI, the issue is more about separating those 
characteristics of a UI component that should be persistent (such as 
what item is selected or what collection is being displayed) from the 
objects used to produce a visual representation of them.  In other 
words, some things that are part of blocks now could move to being 
part of the widgets (or are already there), leaving behind only the 
parts that truly need to be persistent.  The remaining portions would 
then also be directly scriptable for testing purposes in a headless 
environment.

This is of course all hypothetical, depending on the overall 
direction taken.  But basically, if we're going to refactor the 
desktop architecture, we want to increase the independence of the 
visual UI from the application logic, and the application logic from 
the persistence mechanism.  In terms of access transparency, we 
actually want *more* transparency than we currently have.  Ideally, 
it should be possible to completely test the application logic 
without there being *any* persistence dependency OR wx 
dependency...  which incidentally means that you should also be able 
to start and test Chandler's visual components without needing a 
repository, or the application logic, for that matter, as well as the reverse.

In addition to making things easier for everybody to test, this will 
also reduce the amount of bottlenecking/roadblocking we have in 
trying to fix bugs and deliver features, because people doing app 
logic won't have to wait for persistence or UI, and vice-versa.  With 
the appropriate event-management glue, it should be possible for 
application logic and views to be developed in parallel.

These types of separation and improved testing are all things that I 
think we've wanted to have for a long time, but they aren't going to 
happen unless we make them a priority and budget the time for them.