Sharing behavior in the core Read activity
James Simmons
jim.simmons at walgreens.com
Fri Mar 21 10:54:48 EDT 2008
I am trying to give Read Etexts the same sharing behavior that core Read
has, using mostly the same code. Until this week I didn't have a good
way to test sharing, but I have set up multiple instances of
sugar-jhbuild on one of my computers so now I can test sharing. My
sugar installation is missing squeak and another module
(sugar-meta-something) but seems to work OK otherwise.
As a sanity check, I tried to share a document between the two instances
using the core Read activity. This seemed to work OK, at first. I was
surprised at what happened when I resumed the activity from the Journal
of the second instance. If the first instance was still running and
sharing the document, it looked like the second instance would download
the document again and resume on the page where the reader of that
instance had left off. However, when the first instance was shut down
and I tried to resume the activity on the second it displayed an empty
document with zero pages.
This wasn't what I expected to happen. I had assumed that "sharing" a
document meant that the second kid got his own copy of the document,
which would be saved in the Journal until he deleted it.
Again, my sugar-jhbuild has flaws, so I cannot be sure that the behavior
I'm seeing is what is intended. If any of you could confirm or correct
my understanding of this I'd be obliged.
Another thing I remember reading is that if two kids share an activity
and one has an older version of the activity than the other, the older
version gets updated so they both have the newer version. This doesn't
seem to be happening. I have two test machines, one running xubuntu
with the sugar RPMs and another running Suse with sugar-jhbuild. I was
hoping to use this alleged ability of Sugar to update activities in my
testing, so I can develop on the xubuntu machine and test on both
without passing USB drives back and forth. If someone could improve my
understanding of this I'd be grateful.
Thanks,
James Simmons
More information about the Devel
mailing list