Hi,
Sorry if I opened up a can of worms, I just think that this will help in the future when (if) there are more than one repository etc.
all my counter arguments were pretty much added by Ivanovic, but as Tempel said this can be changed when a .pnd format revision goes through as I'm sure that's going to happen sometime soon, the sooner the better I would say otherwise the amount of apps that might need converting to the new format (which are no longer maintained) might grow to a massive amount, and although these might be handled well by the system well it doesn't bode well for any repository.
Kind Regards Jake (milkshake)
Hi there,
I'm not even sure that requiered. Do we want to deliver applications to the user, or packages ? I think we are providing applications. Building them in a bundle is to be more conveniant for everyone. The web archive could display the all the apps independently and link all these to the same pnd-file. I like this idea as it over represent gnome/kde games ;D and imho that the best way to manage current one.
But as this dont have any impact on the running side, pnd_run.sh and libpnd are not impacted. So why not :)
My mains concerns (as the maintener of gnome-games and kde-games) here are that my PXML files are auto generated with genpxml from the information of the desktop files (so if I build an updated version, all I need to do is restart the generator and I'll still have a PXML file with all the versions informations included). These packages information are not to be found anywhere. I guess I'll have to create a package definition file on my side and modify genpxml to use that...
On the other side, I've always been wanting to split author from the packager, so that might be way to do so. I dont see the point of an icon here. None of theses packages have an icon. An icon have only a sense while connected to a launcher, nothing to start no icon ;)
So that would look like : <package> <title lang="en_US">Wesnoth Mega Bundle</title> <packager>EvilDragon, on behalf of Wesnoth team</packager> <desc lang="en_US">....whatever</desc> <version major="4" minor="5" release="0" build="2"/> </package>
Should we make this mandatory, or optional ? If that's optional, then the repo (and the client) will have to manage 2 different type of objects : pnd-package and pnd-app differently. Or always guess the package information out of the (first) application in the pnd, so it can manage all the same way. Made mandatory, obviously, all the current PND are made obsolete, which is bad. In the other end I dont like the idea of having the user to know the difference between a bundle and an app. Nor do I like the idea of the repo guessing the package information from the app information so...
2011/2/27 Jake Aitchison webmaster@liquidfists.com
Sorry if I opened up a can of worms,
No, you didnt :) That's just a good discussion to know if/what to change ;)
Cheers, Sebt3
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 27.02.2011 14:48, schrieb Sébastien Huss:
Hi there,
I'm not even sure that requiered. Do we want to deliver applications to the user, or packages ? I think we are providing applications. Building them in a bundle is to be more conveniant for everyone. The web archive could display the all the apps independently and link all these to the same pnd-file. I like this idea as it over represent gnome/kde games ;D and imho that the best way to manage current one.
With the current information you would have to somewhere mention all the included stuff to eg allow searching for "ksudoku" or other things that are inside the bundles. But since the name for the entry is *only* generated based upon the PXML.xml file (that is the info extracted from it), it would not be possible to have an entry for "kde-games", only the subapplications would have an entry. The main question, since internally the progs are stored with a random name and the name is "created" based on version number and application name at download time, is what the application "package" you download when getting kde-games from the pnd repository should be called. Should it get the name of the first application? Even if you have 40 packages included? Sounds bad to me.
Yes, to make it clear (at least that is what I heard from milkshake): The name the author uses for the pnd is *irrelevant*. He could call the package foo.pnd and the user would *never* see this "foo.pnd", they would get appid-version.pnd, based on the PXML info. This is one place where the packageid makes sense, too. Then it could be called "kde-games" and thats it.
But as this dont have any impact on the running side, pnd_run.sh and libpnd are not impacted. So why not :)
My mains concerns (as the maintener of gnome-games and kde-games) here are that my PXML files are auto generated with genpxml from the information of the desktop files (so if I build an updated version, all I need to do is restart the generator and I'll still have a PXML file with all the versions informations included). These packages information are not to be found anywhere. I guess I'll have to create a package definition file on my side and modify genpxml to use that...
Right, you'd have to create some "definition file" (in a sane way) that is automatically added.
On the other side, I've always been wanting to split author from the packager, so that might be way to do so. I dont see the point of an icon here. None of theses packages have an icon. An icon have only a sense while connected to a launcher, nothing to start no icon ;)
Ah, the icon for some "emulator collection" might be significantly different from the icon of the binary itself. The user would only see this icon in the package repository. There you see some image close to the name, so why not allow using some "specific" icon there?
So that would look like : <package> <title lang="en_US">Wesnoth Mega Bundle</title> <packager>EvilDragon, on behalf of Wesnoth team</packager> <desc lang="en_US">....whatever</desc> <version major="4" minor="5" release="0" build="2"/> </package>
I will "soon" work on a more complete example, but won't be doing so now or in the next one or two days (at least not finish it). Then I will likely have some more complete specification including schema, marking optional/mandatory items and stuff like this. Lets not continue on the exact syntax for the moment but only gather the blocks that make sense as well as those that done make sense.
For example one question is: How to handle license/sourcecode? Should this only be part of the single applications or only in the package or in both? How many of those should be allowed? Should it be mandatory to list a license? ... This point alone already offers some room for thinking and I don't want to do this right now, when I can't test for sure that those blocks will *really* have no impact on the behavior of libpnd.
Should we make this mandatory, or optional ?
Since libpnd has no clue about this the pnds would still work without. But for schema validation we are (partly) more strict, so there it can (and should be!) mandatory. More reasoning below.
If that's optional, then the repo (and the client) will have to manage 2 different type of objects : pnd-package and pnd-app differently. Or always guess the package information out of the (first) application in the pnd, so it can manage all the same way.
IMO it sucks mixing the stuff. Better enforce that packages meant for the repository do also include the correct information required there. For many apps this is likely to be a copy of the existing <application> block anyway (and I'd like to change the schema and redefine it in a way that a simple copy of the block is possible!). This is mainly relevant when >1 application block are used.
Made mandatory, obviously, all the current PND are made obsolete, which is bad. In the other end I dont like the idea of having the user to know the difference between a bundle and an app. Nor do I like the idea of the repo guessing the package information from the app information so...
The user does not have to care since the user never sees the PXML.xml file. The dev should simply know that this is required to follow the schema and have it be accepted in the package repository. Simple as that. Do you really think that any normal user, who never has to manipulate a PXML.xml file has looked at those?
Personally I think it is much cleaner to explicitly define what you got as package. Especially in cases like the kde-games example (other things are of course possible, too, not only gnome games but also eg creating some emulator bundle and whatnot).
2011/2/27 Jake Aitchison <webmaster@liquidfists.com mailto:webmaster@liquidfists.com>
Sorry if I opened up a can of worms,
No, you didnt :) That's just a good discussion to know if/what to change ;)
It makes much sense to get some feedback on proposed changes, since everyone will miss some things, that another one looking over things might spot. So better to have it discussed and explained clearly. It might have been better to directly have started with a more complete explanation of what is wanted/suggested including the reasoning for the blocks. Would probably have reduced the discussions significantly.
Cheers, Nils Kneuper aka Ivanovic