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

[Luke Faraone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/10/2010 03:57 PM, NoiseEHC wrote:
> As I see the problem is that the DS wants to solve a lot of problems in
> a general way. I think that this is simply impossible. A lot of
> companies tried to create some general storage abstraction other that
> files, but all of them failed (even M$ tried that for decades...). My
> prophecy is that you will fail as well.

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

> Now to allow activities to share data they should implement some API to
> be able to provide content to other activities, lets call it
> ContentProvider:
> http://developer.android.com/guide/topics/providers/content-providers.html
> Of course a flag in the MANIFEST could just allow SUGAR to index the
> data automatically.

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

> The remaining piece would be a dead simple Journal which would just list
> the recently launched activities.
[..]
> Now why would it be cool?
> 1. Searching among contacts, mp3 albums and picture bundles can be
> totally different from the end user perspective.

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.


> Why it is just a pipe dream?
> 1. Python does not have anything like the DALVIK virtual machine so
> every Python process consumes a lot of memory. Because of this,
> implementing the above infrastructure would consume all available RAM
> and so would not work. Of course the DS part could be C++ code as well
> but unfortunately children could not look at the source.
> 2. It is already implemented so why bother?

There are a lot of other reasons why the above would not work, but RAM
usage is not one of them.

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.

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.

- -- 
Luke Faraone
http://luke.faraone.cc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkwRRfgACgkQtrC51grHAgbVuwCdHgmahIcRpwzSz305w3fEmFKe
YcQAn2lKYOK2WB9hCQ9edQrzvolJ++IK
=PVk9
-----END PGP SIGNATURE-----