[Sugar-devel] Advice request: XO sound recording

[Art Hunkins]

OK, James and Sasha - then I need additional advice.

There is the Object Chooser method, which seems to do what I need (a 
*general* audio files listing is the appropriate), but is basically 
inoperable on XO-1. OTOH, the FLOSS manual solution(s) would seem to be 
considerably more complex (is this correct? Please recall I am a beginning 
Python programmer.)

I am leaning toward investigating James' algorithms except for one fact: I'm 
not sure that Sugar 0.82 is important to me. Facts: Record on the XO-1 only 
outputs Ogg Speex audio, and Csound on the XO-1 doesn't accept any kind of 
Ogg. OTOH, with 0.84 and up, Record outputs Ogg Vorbis and Csound handles 
the same (on 0.84 Strawberry, a libsndfile update is required). Since Record 
is the primary way that children will get soundfiles into the Journal, I 
wonder whether 0.82 is worth the trouble (i.e., the capability of importing 
child-generated soundfiles).

I know I've not mentioned eToys, but I'm not aware that actual soundfile 
objects that it produces are available through the Journal. (If so, I may 
need to rethink - and would appreciate comments by Bert.) It is also true 
that soundfiles in various acceptable formats (WAV, AIFF, VORBIS) can be 
imported to the Journal via wireless, and presumably accessed there. This 
*might* be an important capability, even for the XO-1.

I *am* convinced that accessing the Journal (nothing else) is the way to go.

So?

Art Hunkins

----- Original Message ----- 
From: "James Simmons" <nicestep at gmail.com>
To: <sugar-devel at lists.sugarlabs.org>
Sent: Monday, October 04, 2010 10:15 AM
Subject: Re: [Sugar-devel] Advice request: XO sound recording


Sascha,

I fully support the way Activities are not allowed write access to
anything but the datastore and their own directories.  I even support
not being able to list out Journal entries at the same time you do
network access.  If we get to the point where an Activity cannot list
out Journal entries (other than using the Object Chooser) at any time
then I've got a beef.

I have tried the Object Chooser.  In Sugar .82 it had some serious
bugs, could not list out only those entries you wanted to look at, and
was slow and ugly.  A big part of my book is explaining how to write
Activities that will run on .82 as well as later versions of Sugar,
and there was no way to make the Object Chooser a part of that
strategy.  As a result I did not discuss it in the book, but did
describe how to write your own object choosing code.  What I described
works well and answers a legitimate need.  In my opinion, nothing I am
recommending would allow anyone to make a malicious Activity (assuming
that listing entries in the data store was blocked during network
access).

James Simmons

> Date: Mon, 04 Oct 2010 10:11:00 +0200
> From: Sascha Silbe <sascha-ml-reply-to-2010-3 at silbe.org>
> Subject: Re: [Sugar-devel] Advice request: XO sound recording
> To: sugar-devel <sugar-devel at lists.sugarlabs.org>
> Message-ID: <1286177910-sup-2358 at twin.sascha.silbe.org>
> Content-Type: text/plain; charset="utf-8"
>
> Excerpts from James Simmons's message of Mon Oct 04 01:28:03 +0200 2010:
>
>> There is a chapter called "Fun With The Journal" which has examples of
>> listing out Journal entries. What you need to do is figure out what
>> the MIME type of the Ogg entries in the Journal are and write code to
>> list them. Then you can put the entries in a GTK table and select
>> them from there.
>
> Just a word of caution: While access to the data store is unrestricted
> because nobody got around to implement the access controls, this won't
> be the case forever. In general you should only assume that you have
> access to the entry belonging to the currently running activity session
> (P_DOCUMENT [1,2]). The Object Chooser is a powerbox [3] that will grant
> your activity access to an additional entry selected by the user (and
> only that one entry, nothing else).
>
> While activities can request additional permissions [4] only certain
> combinations will be granted automatically. In particular listing data
> store entries is mutually exclusive with network access [5]:
>
>>> We solve this by allowing programs to request read-only permissions for
>>> one type of document (e.g. image, audio, text, e-mail) at installation
>>> time, but making that permission (#P_DOCUMENT_RO) mutually exclusive
>>> with asking for any network access at all. A photo viewing program, in
>>> other words, normally has no business connecting to the Internet.
>
> While the user can explicitly grant activities additional permissions,
> we should be careful not to train them to do this for a significant
> number of activities as it would make the system pointless and vulnerable
> to the attacks we're trying to guard the users against (e.g. [6]).
>
> Sascha
>
> [1] http://wiki.laptop.org/go/OLPC_Bitfrost#P_DOCUMENT:_file_store_service
> [2] http://dev.laptop.org/git/security/tree/bitfrost.txt#n874
> [3] http://en.wikipedia.org/wiki/File_dialog#Powerbox
> [4] 
> http://wiki.sugarlabs.org/go/Development_Team/Low-level_Activity_API#Permissions_Declarations
> [5] http://wiki.laptop.org/go/OLPC_Bitfrost#P_DOCUMENT_RO
> [6] http://wiki.laptop.org/go/OLPC_Bitfrost#Compromising_privacy_2
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/