Handling TamTam Resources...
Hi all, I'm working on sharing resources between our 4 activities with respect to the security policy. It will be very helpfull if you have time to give me your opinion on the problem... Here is the situation: TamTamJam and TamTamSynthLab produce sounds that we want usable by any TamTam activities. Each sounds come with a little text file specifying some attributes of the sound (loop points, crossfade duration, amplitude, ...). Before security policy, all our stuff was saved in .sugar/default/tamtam and all activities was looking there for resources... that was working very well. Now, I moved all permanent saved stuff to DATA_DIR and everything work except that others TamTam activity (e.g. TamTamEdit) can't use sounds saved in TamTamJam's DATA_DIR. Is there a way to let all TamTam activities have access to a common directory? How do think this stuff should be implemented? Thank you very much! Olivier Bélanger TamTam's developer team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Handling TamTam Resources...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olivier Bélanger wrote: | Is there a way to let all TamTam activities have access to a common | directory? No. Activities are untrusted code. The security design assumes that every Activity is a trojan horse, unless the user specifically requests otherwise. | How do think this stuff should be implemented? The easiest solution, and the one I recommend, is to make the TamTam activities into a single activity. There is no need to have 4 distinct activities. Switching between screens within one activity seems much more reasonable than running multiple distinct TamTam activities. I cannot keep track of which one is which. If the activities must be separate, I recommend using the P_DOCUMENT_RO model. Whenever SynthLab creates a new sound, it should be added to the datastore as a new entry. TamTamEdit can then run with P_DOCUMENT_RO permission, scan the datastore for all sounds created so far, and load them all. I am not sure about the current state of datastore security; I believe it is minimal. However, if you follow this pattern, you will be appropriately future-proofed. In the Bitfrost design, P_DOCUMENT_RO is mutually exclusive with P_NETWORK by default. If you require both P_DOCUMENT_RO and P_NETWORK for a single activity, you may request this additional permission at install time. When TamTam activities are added before students receive laptops, they will be installed by customization keys, which will also set the desired permissions. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIBUKDUJT6e6HFtqQRAuA1AJ9aiX8cu/DK/XDsBzNc7ta5zu9jNwCfSicH JfAM7kfj6+bFj+5uwau+hqY= =hYOC -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Handling TamTam Resources...
Olivier Bélanger wrote: | Is there a way to let all TamTam activities have access to a common | directory? No. Activities are untrusted code. The security design assumes that every Activity is a trojan horse, unless the user specifically requests otherwise. | How do think this stuff should be implemented? The easiest solution, and the one I recommend, is to make the TamTam activities into a single activity. There is no need to have 4 distinct activities. Switching between screens within one activity seems much more reasonable than running multiple distinct TamTam activities. I cannot keep track of which one is which. Actually, I specifically recommend against this model, myself. The activities each focus on very different overall tasks. One is for composing, another is for performing, yet another is for constructing/editing sounds. I wholeheartedly agree that we need to make them work together as seamlessly as possible, but the do one thing and do it well mantra is one that applies here, I believe. Each interface should be as clean and intuitive as possible, without the need to shuffle around a bunch of different toolbars and views. That's the reason the activity model exists as it does, fullscreen and with identifying icons for each activity. Moreover, keeping them all together emphasizes their interoperability at the expense of generating objects that are available for use in all of sugar. I should be able to make a sound in SynthLab and import that into my Slideshow. I shoul dbe able to record a sound in the Record activity and import that into my TamTamJam session. etc. Finding the correct way to let these activities share objects is crucial to creating the environment we *need* to reach with Sugar as a whole. If the activities must be separate, I recommend using the P_DOCUMENT_RO model. Whenever SynthLab creates a new sound, it should be added to the datastore as a new entry. TamTamEdit can then run with P_DOCUMENT_RO permission, scan the datastore for all sounds created so far, and load them all. This is the method I strongly recommend as well, as it has the advantages I spoke of above. If these objects are created an placed into the Journal, then they can be shared, copied, edited, etc, with any activity that supports their type. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Handling TamTam Resources...
Thanks for quick answers! Le 08-04-15 à 20:43, Eben Eliason a écrit : Olivier Bélanger wrote: | Is there a way to let all TamTam activities have access to a common | directory? No. Activities are untrusted code. The security design assumes that every Activity is a trojan horse, unless the user specifically requests otherwise. OK, it's clear! | How do think this stuff should be implemented? The easiest solution, and the one I recommend, is to make the TamTam activities into a single activity. There is no need to have 4 distinct activities. Switching between screens within one activity seems much more reasonable than running multiple distinct TamTam activities. I cannot keep track of which one is which. Actually, I specifically recommend against this model, myself. The activities each focus on very different overall tasks. One is for composing, another is for performing, yet another is for constructing/editing sounds. I wholeheartedly agree that we need to make them work together as seamlessly as possible, but the do one thing and do it well mantra is one that applies here, I believe. Each interface should be as clean and intuitive as possible, without the need to shuffle around a bunch of different toolbars and views. That's the reason the activity model exists as it does, fullscreen and with identifying icons for each activity. At some point in the past, TamTam was only one activity, with a welcome screen to choose which activity to play with. We were asked to split our activities and I think it was a good call. Most of our activities are now very complex and are design for different purposes. I think the split facilitates learning what each of them does... Moreover, keeping them all together emphasizes their interoperability at the expense of generating objects that are available for use in all of sugar. I should be able to make a sound in SynthLab and import that into my Slideshow. I shoul dbe able to record a sound in the Record activity and import that into my TamTamJam session. etc. Finding the correct way to let these activities share objects is crucial to creating the environment we *need* to reach with Sugar as a whole. I am agree with the example of SynthLab's sound imported into SlideShow, that makes sense... but I don't think it's a good idea to share all our resources. Some sounds will be relevent only inside TamTam environment, musical context, very stripped sound with fine tuned loop points, etc... Can we use the datastore without creating an entry in the Journal (kind of private resources)? Actually, TamTam saves tunes in ogg format in the Journal, this is the files that we really want to import in others activities! If the activities must be separate, I recommend using the P_DOCUMENT_RO model. Whenever SynthLab creates a new sound, it should be added to the datastore as a new entry. TamTamEdit can then run with P_DOCUMENT_RO permission, scan the datastore for all sounds created so far, and load them all. This is the method I strongly recommend as well, as it has the advantages I spoke of above. If these objects are created an placed into the Journal, then they can be shared, copied, edited, etc, with any activity that supports their type. OK, I will look at the P_DOCUMENT_RO model. Is there a template or an activity that does this kind of stuff where I can study the code? Olivier ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
