Diego Escalante wrote:
>> > 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).
>
With your solution _all_ plugins in /home have version 1 and all in /usr
version 2. I think it's better that each plugin has it's own version.
Again refering to Deskbar-Applet: Each plugin contains dictionary that
contains the plugin's information like version, requirements.
>> > 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.
>
That idea sounds great to me. It would be enough to supply a list of
modules that should be available. An easy try: import module_xyz except:
print "plugin not available" would do the trick.
C plugins are another story. NewStuffManager supports no compiling of the
C code, either.
--
Greetings,
Sebastian Pölsterl
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
