Kurosu a écrit : > Pending any investigation on how westnoth/xmoto/... does, here's my reply. > > Matthieu Fertré a écrit : > >>> - Identifier (version number, CRC?) to differentiate versions or maps >>> >> I guess that in case of version number, the identifier would be the >> couple Name-version number. >> > > Yes, otherwise, indeed, there would be duplicated identifiers. > > >>> - Author (optional, only small hint as to if the map is any good) >>> - Jpeg thumbnail (the one already available) >>> - Compressed (downloaded) and decompressed sizes (worth it?) >>> >>> >> Should we really means those information ? >> > > The 3 above? I think the jpeg thumbnail is really important: how to pick > up a map otherwise? > > Compressed/raw sizes are mostly for low bandwidth connections: for many > people, a 2s or 10s download doesn't make much of a difference. >
I was only talking about the sizes, but you're right. > >> Ok for the URL. We are ok that maps will be either downloadable from >> gna.org or wormux.org ? Should we accept maps from another place (not >> urgent question to answer ;)). >> > > I think that this would leave us open to unforeseen exploits. We could > allow to specify additional urls where to get lists, but then the user > should be made aware of the risks (security, rudeness, ...), and this is > overall burdensome. > > But as you say, at least we need it to work for a gna/wormux endorsed place. > > >> Finally, I would choose a md5 hash from the zip file to identify the >> map. Thus, all the xml file could be generated from a script without >> manual intervention :) >> > > Good idea. Do we have a MD5 calculation tool inside of wormux (or its > relevant libs, like curl)? Can be implemented otherwise > No, we don't have it. > >>> In addition, what about future: >>> - minimal version to understand the xml file? >>> - minimal version to play the map? >>> >> Well, I think something like "compatible versions" is enough. "Minimal" >> is not always good as some things may become deprecated. >> > > "compatible" sounds like a list should be provided, which is a bit > bothersome. I was more thinking of an internal revision name (like > format v10) for easy verification: can't handle this xml/can't handle > this map because my internal version is below what's written > Ok, that's ok for me > >>> 2) Display: >>> img|name|author|version|"new"/"updated"/no img|compressed size|raw size >>> >> What do you mean by "no img" ? "updated" since when ? >> > > The column where this appears is either empty, with an image with "new" > within when the map is "new", same for "updated". > > Let's consider we already have a list (empty, or from a previously > downloaded xml), named "old", and a new one, called "current". What I > mean is: > - a "new" map is one which name was not present in the "old" list, and > is in the "new" one > - a "updated" map is one which name is present in both, but with > different identifiers in each of the 2 > > There would also be the need of "removed" image: a map might be removed > (because of a copyright violation or any other kind of valid complaint) > from the website but still present on the computer. This is starting to > be very precise, because one could consider that the reason of the > removal should be mentioned then. > > >> What do you mean by "delete map(s)" ? Delete a map that has been >> previously downloaded ? >> >> If so, there must be a read-only checkbox indicating if the map has been >> previously downloaded. >> > > Indeed, I had forgotten to put it in the mockup. > > In addition (but not as an alternative), the "remove" button could be > hidden/made inactive for already downloaded maps. > > >>> - Hitting "refresh list" >>> . Fetches list from 1), and update listbox from 2) (what about >>> displaying "new" and "updated" about maps?) >>> >> We can imagine sorting by this attribute or use a different background >> color. >> > > What do you mean? Sorting by "new"/"updated"? What would the different > background conveys? The "new"/"updated" status (instead of an image)? > The "has been downloaded in this session"? > Yes, that was all of that > >>> . One or several maps at a time? does listbox allow this? >>> >> Yes, listbox allows this :) It was designed to select teams at the >> beginning :) >> > > Perfect, because it could become burdensome in some occasion. > > >>> . Downloads and unpack to a temporary folder: >>> - wormux personal dir vs TEMP: security issues >>> >> I vote for wormux personal dir >> > > I guess using the MD5 to validate the download (this is http/tcp, I > know) is sufficient for one part. Then for the conformance validation, > maybe it's up to the game engine, and doesn't belong here, but this was > another reason for the TEMP folder. > To my mind, the validation must firstly be done by our team, as for the current bonus map pack ;) > My problem with "personal" folder is that it is, well, personal, and may > not benefit every user. Yes, but this is inherent of operations that are not be done by an administrator. > OK, on that point, probably nobody has 2 users > on a computer using wormux. :) > > I now see there is a problem under windows: the chat logs, personal > teams and maps folders are the same as the "config" folder. This is a > problem because the later is in a hidden (yet endorsed in the windows > way of storing user application config) folder. Under Unix, Wormux follows freedesktop draft and uses ~/.local/share/wormux/ that is a hidden folder too. > Maybe a more accessible > folder (like "Documents") should be used instead => need to perform > migration. > I don't think user want a "wormux" directory in his home directory. The only problem I see is uninstallation. In that case, when uninstalling wormux under windows, you can propose to empty to remove all those data for all users. > Regards, > Kurosu > Regards, Matt (gentildemon) _______________________________________________ Wormux-dev mailing list Wormux-dev@gna.org https://mail.gna.org/listinfo/wormux-dev
