Re: Introducing NewStuffManager
- From: "Diego Escalante" <diego aureal com pe>
- To: "Sebastian Pölsterl" <marduk k-d-w org>
- Cc: desktop-devel-list gnome org
- Subject: Re: Introducing NewStuffManager
- Date: Sun, 8 Oct 2006 20:17:22 -0500
First of all, congratulations to everyone involved in NSM. I think
it's a great idea.
Let me give my humble opinion on this
On 10/8/06, Sebastian Pölsterl <marduk k-d-w org> wrote:
Tom Tromey wrote:
>
> I've got a few questions about it. I've tried to read through all the
> available info -- forgive me if I missed something.
>
> First, you may want to read through the JNLP spec[1] for ideas. JNLP
> is more or less the equivalent java technology, though a bit more
> application-centric.
>
Afaik Java Web Start is used to run applications over the web instead of
downloading and installing them first. NewStuffManager tries not to
achieve such goal.
> What happens if a distro wants to ship a plugin? I'm specifically
> thinking about upgrades and versioning, and making sure the manager
> does the right thing. E.g., consider this scenario: the distro ships
> a plugin (version 1), then the user updates from the update site
> (version 2) into his home directory, and then the OS itself is
> upgraded, pulling in version 3. (If this sounds far-fetched... I've
> done this multiple times with Eclipse plugins on Fedora.)
>
Okay, let's say you have version 1 of the plugin installed. Then you have
to call NewStuff.GetAvailableUpdates([("id_of_myplugin", "1.0.0.0")]) to
findout if an update is available. This call returns [("id_of_myplugin",
"2.0.0.0")]. So NewStuffManager downloads and installs version 2 of the
plugin. After that your distro updates to version 3. If you call
NewStuff.GetAvailableUpdates([("id_of_myplugin", "3.0.0.0")]) the return
value won't contain an entry for "id_of_myplugin" anymore. Therefore, no
update is available. Of course, the version of the installed plugin must
be stored in the plugin itsself or the application that uses it,
I understand then that applications that relay on NSM in the future
will have to do some logic like "plugin in /usr is 2.0 but plugin in
/home is 1.0, I will prefer the one in /usr". I don't see a lot of
scenarios where users would kill for an older version of a plugin and
in any case they can rename the plugin in /home so it's a different
plugin with it's own version (and it's never updated).
> Is there any way for a plugin to express its requirements? Maybe it
> needs other plugins, or specific versions of things, or ... your idea
> here. This sort of thing is a staple of other plugin management
> environments. (Eclipse for sure, which goes the overkill route. JNLP
> has a lighter touch, basically allowing re-use via URLs, though having
> a tag to indicate the required JRE version.)
>
Currently, there's no way to do this via NewStuffManager. Deskbar-Applet
plugins can contain a function that check the requirements, though. If
some of the requirements are missing the plugin isn't loaded by
deskbar-applet.
Python plugins would be easy to check (I think) since probing via
Python if the module foo is available would be enough, if it's not
found NSM can make a guess like "looks like you are missing module
foo, that's required for this plugin. Look for python-foo in your
distribution.". More than that would be a little too optimistic for a
human maintained list.
C plugins might be another history (but actually, I don't know if
writing C plugins should be promoted at all)...
Mabye, it's a good idea to implement a way to allow a plugin to express
its requirements. I'm grateful for any suggestion.
I'm a Python fan, so I must insist that mentioning in the XML that the
plugin needs module foo, bar, cuac would be enough for any Python
plugin. C ones would be harder.
> How does this relate to python eggs[2]? And if it doesn't, why not?
> It seems to me that if there's an upstream project that handles a lot
> of this, then it would be beneficial to simply re-use it.
>
eggs are something like a setup wizard. You pack your files into an egg so
that the user can install the application easily. I don't know what you
mean. Do you want to support eggs as an download source, or what?
Python eggs have a totally different purpouse I think, but ideas can
be taken from there I guess.
Greetings!
--
"First they ignore you, then they laugh at you, then they fight you,
then you win" -Ghandi
http://diego.aureal.com.pe | http://diegoe.blogspot.com |
http://barsafan.wordpress.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]