[Sugar-devel] [DESIGN] for Journal Plugins feature

[Bert Freudenberg]

On 28.11.2009, at 19:17, Aleksey Lim wrote:
> 
> On Sat, Nov 28, 2009 at 06:08:53PM +0000, Aleksey Lim wrote:
>> On Sat, Nov 28, 2009 at 06:59:51PM +0100, Bert Freudenberg wrote:
>>> On 28.11.2009, at 17:16, Aleksey Lim wrote:
>>>> 
>>>> On Sat, Nov 28, 2009 at 04:24:30PM +0100, Bert Freudenberg wrote:
>>>>> On 27.11.2009, at 17:15, Aleksey Lim wrote:
>>>>>> 
>>>>>> On Fri, Nov 27, 2009 at 04:57:40PM +0100, Bert Freudenberg wrote:
>>>>>>> On 27.11.2009, at 07:13, Aleksey Lim wrote:
>>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> Want to know what people think about Journal Plugins feature[1]
>>>>>>>> and particularly that design team think about UI changes[2] involved
>>>>>>>> in this feature.
>>>>>>>> 
>>>>>>>> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#
>>>>>>>> [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes
>>>>>>> 
>>>>>>> I like the idea.
>>>>>>> 
>>>>>>> Reminds me of how in OS X, the Finder can be extended to support more file formats by a plugin stored in an application bundle. The Finder knows how to show previews for several document types (audio, video, multi-page document). It recognizes a limited set of formats (like jpg, mov, pdf), and the app's plugin simply needs to convert its own format into one of these formats. 
>>>>>> 
>>>>>> yup, I had the same in mind, API will let Journal plugin to use query
>>>>>> (tags(which include MIME types tags) and search string) to restrict
>>>>>> final set of objects
>>>>>> 
>>>>>>> That's a lot simpler than having to write an actual viewer plugin (which also would have to be maintained for every new version of the viewer). E.g., Etoys stores a thumbnail in its project file which are simply zipped, so the preview plugin just extracts the thumbnail picture from the project. Tt does not have to care about the actual UI used to display the thumbnail.
>>>>>> 
>>>>>> there is another benefit for separate plugins -
>>>>>> plugins could be out of sugar release cycle(;P to core maintainers)
>>>>>> 
>>>>>> -- 
>>>>>> Aleksey
>>>>> 
>>>>> I'm not sure we are talking about the same thing, though maybe we do - so I'll be explicit:
>>>>> 
>>>>> I'm suggesting that activities would contain those plugins for the types they support.
>>>> 
>>>> got it, but not sure, we can get the same result with preview feature,
>>>> in preview() every activity can "convert" its object to image, in my mind
>>>> its more useful(at least for now) then complicated system with preview
>>>> plugins.
>>> 
>>> That works only if the activity is running. The bundle-provided converter can be run any time, like when downloading a file or from a USB stick.
>> 
>> but preview image could be embedded[3] to USB file
>> (if we are talking about objects that activity supports, thus about
>> regular activity objects that have preview field, and not about
>> non-sugar objects)
> 
> but if we are talking about non-sugar objects(e.g. plain video which could be
> opened in Jukebox), there could be another issue in having preview
> plugins that come from activities - security reasons. [1] proposes
> API for plugins that could/should be well checked for malicious code.
> But if any activity can leave "resident part"(preview plugin) in shell
> which will be started in shell process...

If the bundle just provides a file converter there is no need to run it in-process. This may not cover every use case, but maybe the majority (e.g. for creating a preview image).

As I said, maybe we are talking about two different issues - one is modularizing the Journal code and allowing plugins there, the other extending activity bundles to provide preview creation scripts.

- Bert -

> 
>> [3] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles
> 
> -- 
> Aleksey