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

[Aleksey Lim]

On Tue, Dec 08, 2009 at 10:05:30AM +0100, Simon Schampijer wrote:
> On 12/07/2009 01:09 PM, Aleksey Lim wrote:
> > On Mon, Dec 07, 2009 at 10:57:01AM +0100, Simon Schampijer wrote:
> >> On 12/07/2009 05:58 AM, Aleksey Lim wrote:
> >>> The core idea of plugins is exactly to avoid situation when we have to
> >>> release fat UI change set, plugins let us decentralize existed scheme
> >>> when entirely sugar design(not only UI) depends on what core team
> >>> thinks. We just provide usable toolset developers cold use to implement
> >>> what they think.
> >>>
> >>> [1] proposes UI changes in [2] but plugins API could be implemented w/o
> >>> any UI changes at all - user will see the same Journal(but it will be
> >>> Journal plugin). The idea is let developers make plugin out of sucrose
> >>> release cycle, yeah developers could do it in pure activities(but see
> >>> [3]) and even out of sugar at all, but imho it will be useful(in all
> >>> cases, not only technical) to initiate/support/organize such process
> >>> from core.
> >>>
> >>> [3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description
> >>
> >> Generally the idea of plugins is interesting - it always adds
> >> extensibility and make parts exchangeable. In the Journal case it is the
> >> support for different pluggable views. Looking just at the idea: great!
> >>
> >> Let's take a concrete example of a scenario with different views that is
> >> floating around: the action/object view. While there have been some pros
> >> for the change to have these two views, the implementation could be done
> >> using plugins or not. From a technical point of view: while having to
> >> change code it might be a good moment to add a plugin structure.
> >
> > 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.
> >
> > 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.
> 
> I prefer to have a plugins over activities - here I agree. Do you have a 
> layout of the plugins structure already? How much code/how invasive is it?

iiuc, new feature should be included to new release cycle before
starting development process, so I don't have detailed plan for plugins
structure, but I guess it should mean at least refactoring of existed
Journal code and I also think to include remote objects to model
abstraction.

-- 
Aleksey