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, > 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. Mabye, it's a good idea to implement a way to allow a plugin to express its requirements. I'm grateful for any suggestion. > 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? -- Greetings, Sebastian Pölsterl _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list