[Sugar-devel] GSoC idea: Chart/graph-making activity

[Benjamin M. Schwartz]

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

Walter Bender wrote:
> I thought Fred was getting at a much simpler idea. For example,
> Measure, when it is collaborating, is sending a simple data stream to
> each member of the collaboration. Why couldn't a chart program join in
> and instead of rendering the datastream as a waveform, it would render
> it as a piechart. Of course, we'd need to consider that the chart
> program wouldn't be generating data, but if an activity which wants to
> share its data with other activities sticks to a simple streaming
> protocol, I don't think it is too difficult.

That's a nice idea, really.  What I'm saying is: it's not difficult to
build it once, but it's difficult to ensure reliability when there are 100
versions of Measure and 100 versions of Chart, and they've each gone
through countless revisions of the datastream format.  Sugar is designed
to encourage forking, which makes this sort of compatibility very hard.

In the early days of Sugar this sort of problem happened frequently with
central components of the system, causing "flag days" where multiple
components of the system had to be upgraded simultaneously in order to
maintain functionality.  Clearly we can't achieve "flag day" upgrades of
Activities, given our distributed development model.

I have long pushed, and am continuing to push, a model in which any two
people collaborating are using the _exact same Activity_.  That is, upon
joining someone's shared activity, if I don't have that precise bundle
already, my system will silently download it, launch it, and join.
(Bitfrost exists precisely to make this procedure safe.)  That way, an
Activity author only has to ensure that her code is compatible with itself.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAknKtnMACgkQUJT6e6HFtqT5RgCfUhjENDiOaR9IxqhEUGXpuQYh
y4AAn2nbuz4+o8C8SGm2DycmyVwEpAig
=XeHc
-----END PGP SIGNATURE-----