[MonoDevelop] Ideas for an addin manager

[Lluis Sanchez]

> "Enabling/disabling of addins would require restarting MD. Doing it on
> the fly would be really hard to implement with the current design":
> 
> It would be cool if we could do it though. Maybe we could do it for
> some of the addins while others might require restarting MD.

Maybe we can do it in some cases, but if an addin adds menu entries,
pads, views, or any other UI element, it will be really hard to do it
right. It would prolly require a redesign of the whole addin system.

> 
> "We need a way of specifying the dependencies of an addin in a
> declarative way.":
> 
> Why would we need that? Can we just not examine the assembly as it is
> to determine the dependencies. Also we might just try and instantiate
> it inside a try/catch or are things not that simple?

If we have information about dependencies we can check them even before
the addin is downloaded from the repository. It's better to show a
message saying that "the debugger addin can't be
downloaded/installed/enabled because the Mono debugger is not
available", than to show an error about "Mono.Debugger.dll not found".

We write software for users, not for hackers.

> 
> /Jacob
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 7/4/05, Lluis Sanchez <lluis at ximian.com> wrote:
> > Hi!
> > 
> > One of the good things of MD addins is that in most of cases they can be
> > implemented in fully managed code, which means that the same binary can
> > be safely distributed to any platform that runs MD. I'm writing here
> > some ideas about how could we take advantage of this.
> > 
> > >From the user's point of view, I envision the following features:
> >       * A dialog shows a list of addins installed in MD.
> >       * The addins can be enabled / disabled.
> >       * When the user enables an addin, MD checks that the dependencies
> >         of that addin are installed in the system, and shows an error
> >         message if they are not.
> >       * Addins can be downloaded from internet. There is a list of
> >         addins which are available for download. The list is taken from
> >         a repository of addins. The user can register new repositories
> >         by just adding new urls.
> >       * Addins downloaded from internet can be easily updated when a new
> >         version is published.
> > 
> > Now some technical notes:
> >       * Enabling/disabling of addins would require restarting MD. Doing
> >         it on the fly would be really hard to implement with the current
> >         design.
> >       * We need a way of specifying the dependencies of an addin in a
> >         declarative way.
> >       * An addin may depend on other addins.
> >       * Because of the previous point, MD should take care of making
> >         sure that addins can find the addin assemblies they depend upon.
> >       * Some addins will have uncommon unmanaged dependencies, which
> >         will need to be installed by using whatever system it's Linux
> >         distribution is based on. This new addin management system would
> >         not be so useful in this case, but I think that there are many
> >         other cases in which it would be really useful.
> >       * If an addin only has managed dependencies (for example, the boo
> >         compiler), an option would be to package those dependencies
> >         together with the addin.
> >       * A repository of addins could be something as simple as an XML
> >         file with the list of addins (and its dependencies and versions)
> >         together with gziped assemblies.
> >       * There would be an "official" MD repository of addins, with the
> >         optional addins we are not currently shipping.
> > 
> > Any comment about this?
> > 
> > BTW, I don't think I'm going to implement this at short term, so if
> > people agree that something like this is needed and somebody has some
> > free time, feel free to take it, it shouldn't be too difficult to do,
> > and looks like fun ;-)
> > 
> > Lluis.
> > 
> > 
> > _______________________________________________
> > Monodevelop-list mailing list
> > Monodevelop-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/monodevelop-list
> >