#4497 NORM Never A: RecordActivity: Improvements to design and efficiency of Tubes use
Zarro Boogs per Child
bugtracker at laptop.org
Mon Oct 29 08:13:34 EDT 2007
#4497: RecordActivity: Improvements to design and efficiency of Tubes use
-----------------------------+----------------------------------------------
Reporter: smcv | Owner: erikb
Type: defect | Status: new
Priority: normal | Milestone: Never Assigned
Component: camera-activity | Version:
Keywords: collaboration | Verified: 0
-----------------------------+----------------------------------------------
On Sun, 28 Oct 2007 at 22:55:32 -0400, Erik Blankinship wrote:
> If you've a moment, please take a look at the attached version of Record
> which is happily on Tubes and working well for me with three xos.
Is this code available in git, svn, ... anywhere?
In general, the code looks unnecessarily complicated; I could be wrong,
though, it might need to be this complicated.
> When a photo is taken, xml is broadcast to everyone with a thumbnail and
> metadata such as md5sum of the photo.
"You have a problem, which you solve with XML. Now you have two problems"
:-)
Why XML? D-Bus already has data structures... if you want arbitrary
optional key/value pairs, use a dict of signature a{sv}, or a{ss} if the
value is constrained to be a string.
You shouldn't be Base64'ing the thumbnail - that causes 33% extra bloat.
The Tubes implementation ensures that you get a binary-safe channel for
your data. Either use a separate argument of type 'ay', or a key of type
'ay' in your a{sv} dict.
The signal shouldn't be called notifyBudsOfNewRecd, it should be called
something like NewRecording or RecordingAdded. You can add a (non-D-Bus)
method notifyBudsOfNewRecd that just calls NewRecording, if you strongly
prefer that naming.
The signal doesn't need to have the "recorder" argument. When receiving
the signal you should just use the "sender" argument to tell who it came
from.
In general, hashing the public keys makes no sense. We already have more
unique identifiers than we know what to do with... (channel-specific
handles and buddy object paths can be used locally; the strings
represented by the channel-specific handles, and the unique-names in the
tube, can be used locally or in the Tube API).
> When someone clicks a thumbnail, then they request that photo from who
took
> it.
Are these the required semantics, or would it be acceptable for whoever
took the photo to just broadcast the bits to everyone? ("Lazily", of
course...)
If everyone is expected to want to see everyone's photos, this would be
considerably more efficient in the link-local protocol (we use multicast,
so the broadcasts literally do go to everyone in the activity) and
slightly more efficient in the server protocol (one "upload" to the server
and n "downloads", instead of n "uploads" and n "downloads").
> If that other person responds, "I've deleted it" or have left the
activity,
> then we ask the next buddy, etc.
> If we never hear from that other person, we move on and ask the next
person.
> If the other person has it, they send it over in chunks.
You're sending the data in a stream of broadcast signals that go to
everyone, then ignoring signals that are "not for us". Please don't do
that! D-Bus Tubes already know about directed messages.
The right way to send the data would be either over a stream tube (see
patches attached to #4297) or via replies to method calls that ask for
individual chunks of the file (see comments on your patches to
ReadActivity, also in #4297).
Other notes:
RecordTube is badly named - it's not a tube, it's an exported object. You
can export many objects, if you need to. Personally, I'd go for an API
with multiple objects, something like this.
{{{
* RecordingManager object
Path: /org/laptop/RecordActivity/Manager
Interface: org.laptop.RecordActivity.RecordingManager
* signal RecordingMade (o: path, a{sv}: properties)
Indicate that this XO has taken a new photo/video/etc.
properties contains things like:
'title' => the title as a dbus.String
'thumbnail' => the thumbnail as a dbus.ByteArray
'md5' => the MD5sum as a dbus.ByteArray
'length' => the length as a dbus.UInt32
'color-stroke' => the buddy's stroke colour as a dbus.String
'color-fill' => the buddy's fill colour as a dbus.String
etc.
This signal should only be emitted after the XO has attached
the Recording object to the Tube.
* signal RecordingCopied (o: path, a{sv}: properties)
Indicate that this XO has received a copy of someone else's
recording, and is now sharing it with the same object-path
and properties that they were using. This should only be
emitted after the XO has received the whole file and verified
the MD5sum.
* signal ListRecordings () -> a(oa{sv})
Return a list of structs (~= tuples) each containing the
object-path of a recording, and the properties
* Recording object
Path: /org/laptop/RecordActivity/Recordings/IDunique_id
where unique_id is some unique identifier (maybe the MD5 in hex)
Interface: org.laptop.RecordActivity.Recording
* signal ChunkBroadcast (u: offset, ay: bytes)
* method GetChunk (u: offset, u: count) -> ay: bytes
* signal Deleted ()
}}}
To listen for the ChunkBroadcast signal you should use the tube object's
add_signal_receiver method with path_keyword and sender_keyword arguments,
so you can associate chunks with recordings as soon as you receive them.
GetChunk only exists to be able to catch up with recordings you missed;
for still-greater efficiency on this, you could use a stream tube.
Consult the dbus-python tutorial http://dbus.freedesktop.org/doc/dbus-
python/doc/tutorial.html for how to use byte arrays efficiently. (Briefly:
use the byte_arrays=True keyword argument all over the place)
There is also no requirement for your signal listeners to be part of the
RecordTube object. I'd be inclined to move them to the Activity.
--
Ticket URL: <https://dev.laptop.org/ticket/4497>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system
More information about the Bugs
mailing list