[Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[NoiseEHC]

> You are not explaining why this will happen, so this point is moot.
>
>   

The reason is that it seems that it is impossible to do. I just 
extrapolated historical data.

> So we're indexing the data "automatically", but we still don't have a
> datastore? Please explain how that would work.
>
>   

The Search activity's data is the generated index.


> And we want users to have to start other applications to find there
> stuff *why*? From what I can tell, the trend in the mobile space has
> been to unify searching across formats, a la the iOS's Spotlight.
>
>   

Exactly. Launch Pictures to handle pictures and launch Write to handle 
documents. You can have unified search across formats just not unified 
object handling (display, delete, etc).


> You'll be breaking backwards compatibility with every previous Sugar
> version (from what I can tell by your description), and rather than
> requring us to rewrite the Journal every so often in Sugar, each
> activity maintainer will have to rewrite it themselves.
>
>   

Now here is the interesting part. You already break compatibility.


> If there is shared code between these activities (since most cases
> involve similar models of data storage) we'll have to patch each
> individually, rather than a shared library.
>
>   

That is the point, to not have shared DS code other than some library 
what would be included in every activity which would provide some data 
to search or other activities. Most activities will not have such data. 
The few activities which would have such DS could be updated 
individually without breaking compatibility. They could be developed 
individually *when* *the* *need* *arises*.


Now all that said, the Android model is overkill. Something much-much 
simpler could work IMHO.