>>>>> "Sebastian" == Sebastian Pölsterl <[EMAIL PROTECTED]> writes:
Sebastian> I'm posting this here to encourage you to read my Sebastian> presentation at Sebastian> http://www.k-d-w.org/clipboard/NewStuffManager/ and to find Sebastian> out what you are expecting from such an application. 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. 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.) 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.) 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. Anyway, I think the idea as a whole is a pretty good one. Tom [1] http://java.sun.com/products/javawebstart/1.2/docs/developersguide.html [2] http://cheeseshop.python.org/pypi _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
