Fallbacks for packages

[Marco Martin]

On Tuesday 22 July 2014 11:27:48 Sebastian Kügler wrote:
> > And a last one, would be to just use two packages in the client code. It
> > would  be the solution i would normally prefer, but since the look and
> > feel
> > package is accessed by too many different processes, entry points, it
> > would
> > mean a lot of duplication of error prone code.
> > 
> > opinions? comments?
> 
> I think the main problem with one, or a hardcoded fallback is that, we might
> not always want to fall back to for example the desktop shell, or do we?
> People might want to customize certain aspects of the shell, and then want
> to fall back on the tablet or desktop shell, depending. I've been wondering
> how we can express that. For that reason, I think we might need a flexible
> fallback, which means solution 1 you propose.

yeah, seems useful in many situations.
however, the concern i have is the following:
basically, any plasmoid being able to depend from nay other plasmoid..
so any random change, would break the depending plasmoids. This violates the 
isolation promise that is one of the points o Package..

thinking..
there should be something to define that the package can be used as a 
fallback.. may depend from the package structure so only some types of 
packages would allow it, or the package providing a file that contains a 
whitelist of files it can expose..
hmm

-- 
Marco Martin