Should queryables implement topsConcurrent?

[GoogleCodeExporter]

It might make sense for dotsQueryable or dotsTheQueryablessManager to implement 
the topsConcurrent interface.  This would be consistent with the 
dotsAllRemoteObjectManagers implementation of it.

It would allow an object or manager to run along with other concurrents.  
However, do users need to have finer control of what gets updated, when?

If dotsTheQueryablesManager were a topsConcurrent, what exactly would it do to 
runBriefly()?  Call some update on each of its managedObjects?  Could multiple 
calls to mexHID('check') get coalesced?   This would be the whole point, I 
think.

If dotsAllRemoteObjectManagers and dotsTheQueryablesManager are going to 
implement topsConcurrent, then dotsAllObjectManagers should implement it.

Original issue reported on code.google.com by Benjamin.Heasly on 3 Aug 2010 at 6:18

[GoogleCodeExporter]

Original comment by Benjamin.Heasly on 4 Aug 2010 at 6:59

• Changed state: New

[GoogleCodeExporter]

In emails with Andrew Lui, this came up again.  He anticipated this feature 
even though it doesn't exist, asking whether runBriefly() would automatically 
do readData or similar on behalf of its managedObjects.

I'm leaning towards implementing this, after November2010.

Original comment by Benjamin.Heasly on 27 Sep 2010 at 10:12

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

This would relate to issue 46, about whether allObjectManagers should have a 
concept of activeGroup.  If so, the activeObjects might be the ones to have 
readData automatically called.

Original comment by Benjamin.Heasly on 27 Sep 2010 at 10:14

• Changed state: Accepted

[GoogleCodeExporter]

Another answer would be to get rid of dotsTheQueryablesManager.  As of 
October2011, it's not doing very much.  If it's not going to do much, then 
getting rid of it would remove confusion about what it's for.

dotsTheQueryablesManager is the only concrete subclass of 
dotsAllObjectManagers, so removing it would raise a follow-up question: is 
there any reason to have non-remote managers?

This relates to questions in the DesignIssues wiki page.  Maybe object 
management and remote object distribution are different problems and should be 
redesigned alltogether.

So this issue needs to wait in larger issues...

Original comment by Benjamin.Heasly on 28 Oct 2011 at 2:15

[GoogleCodeExporter]

This issue will become moot, as of version 1.0.

TheQueryablesManager will be removed altogether.  Queryables will be replaced 
with Readables.  Individual Readables should be aggregated by topsConcurrent 
objects, but need not inherit Concurrent.

Original comment by Benjamin.Heasly on 8 Jan 2012 at 9:56

• Changed state: WontFix