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

[Aleksey Lim]

On Mon, Dec 07, 2009 at 02:01:16PM +0100, Sascha Silbe wrote:
> On Mon, Dec 07, 2009 at 12:09:59PM +0000, Aleksey Lim wrote:
> 
> 
> 
> Sorry I didn't enter into the other discussions about your features yet; 
> I'm having quite a hard time understanding most of what you write. Would 
> be nice if you could try to be more elaborate and explain your use cases 
> and goals in more detail as that is likely to increase my understanding.
> 
> 
> > Well, I guess there are two obvious ways, coding pure activities or
> > having several views(somehow) in core. I tried 1st way while 
> > developing
> > Library activity in 0.84 release cycle and, at the end, I realized 
> > that
> > I copy/pasted much code from the shell, so tried to reimplement shell.
> What did you copy most of the time? UI code or backend? If the latter, 
> why? I.e. in which way was the data store API insufficient for your 
> activity?

UI, since I had the same widgets(activity, stared icons, list widget
etc), lazy model and shell code to launch objects, edit them etc

> > So, we can just extend shell public API but there could be another
> > issue - security reasons. I heard about plans to restrict activities 
> > in
> > case of searching/changing/removing objects that were not created by
> > this activity. Having special API(and plugins) could soften situation
> > then.
> No, it will just raise exactly the same concerns again that were the 
> reason for including such restrictions in Bitfrost/Rainbow, leading to 
> exactly the same solutions (only certain combinations of rights granted 
> by default; elevated privileges by using signed builds or explicit user 
> configuration).
> According to [1], those restrictions where never actually implemented. 
> So when they are, we can take the use case "Data store explorer" into 
> account and see whether there's anything we could do differently to 
> address it. No need to design a new API to work around it, especially 
> given it's a deliberate design decision.

as I said, we can improve shell API, it will let activities launch
Journal objects, having default list widget, default propery dialog,
model for lazy displaying, model could provide source abstraction as
well(e.g. could be useful to browse remote Journal objects, not only
local or having subset of local/remote objects)

> There will always be a way for the _user_ to gain full control (*) and 
> thus grant any privilege to any activity, BTW:
> 
> [2]:
> >     No lockdown
> >         Though in their default settings, the laptop's security 
> > systems may impose various prohibitions on the user's actions, there 
> > must exist a way for these security systems to be disabled. When that 
> > is the case, the machine will grant the user complete control.
> 
> 
> [1] http://wiki.laptop.org/go/Bitfrost#Current_Status
> [2] http://wiki.laptop.org/go/Bitfrost#Principles
> (*) At least from the upstream side. Any computer can be locked down to 
> prevent the user from tampering with it (which again can be broken with 
> enough sophistication from the user), there's nothing we can do about 
> it. Whoever disables root access etc. is likely to disable Journal 
> plugins and similar elevated rights as well.
> 
> CU Sascha
> 
> -- 
> http://sascha.silbe.org/
> http://www.infra-silbe.de/



> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel


-- 
Aleksey