Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Markerpacks - Updating / Meta-Data / Structure #91

Open
chland opened this issue May 24, 2019 · 2 comments
Open

Markerpacks - Updating / Meta-Data / Structure #91

chland opened this issue May 24, 2019 · 2 comments

Comments

@chland
Copy link

chland commented May 24, 2019

System for Marker-Updates

I know that this idea was already mentioned (I think its also on the Trello-page) but I thought i would write a little draft on how it could work.

The basic idea would be to ONLY use ZIP-files for marker-packs that contain at least 1 file - the so called packinfo.xml

The "packinfo.xml"-file would look like this:

<?xml version="1.0" encoding="utf-8"?>
<PackData>
	<Author>
		<Name>Tiscan</Name>
		<InGame>Tiscan.8345</InGame>
		<Email>[email protected]</Email>
		<Website>http://gw2info.net</Website>
	</Author>
	<Meta>
		<Name>Skyscale Markers</Name>
		<Description>A simple pack containing markers for the Skyscale-Collections in Dragonfall.</Description>
		<Version>1.0.0</Version>
		<UUID>61cfb756-c080-4850-875b-ac60048e50f8</UUID>
		<FileURL>http://markers.gw2info.net/files/gw2i_skyscale.zip</FileURL>
		<UpdateURL>http://markers.gw2info.net/files/gw2i_skyscale.xml</UpdateURL>
	</Meta>
</PackData>

Most of the fields would be optional (InGame, Email, Website, Description, etc.)

The only mandatory fields would be the two Name Fields and the UUID-Field.

Updating would work like this:

Blish would try to download the xml-file from the URL stored in "UpdateURL". This XML-File would be a copy of the packinfo.xml - Blish would then first compare the UUID and if they match, it would compare the values of the "Version"-field. If the Version from the XML that's found on the server is higher, Blish would download the file given in "FileURL".

The UUID would ALWAYS stay the same for a certain markerpack. so no matter if you have version 1, 2 or 349 or a pack - the UUID would always match (that way, Blish could also decide to skip loading a pack to prevent duplicate packs)

And in case you're wondering why i said that only the packinfo.xml is madatory: this way a pack-creator could create a base-pack with images for all his packs and ship all other packs without any images in them.

Which brings me to another possible addition: dependencies. By having unique UUIDs for all packs, we could also add a "DependsOn" Field containing the UUID of another pack.

I don't know if there are already other plans but i thought i would just post this here so you guys can make use/fun of it :) :) :)

@chland
Copy link
Author

chland commented May 24, 2019

Oh, and just in case somebody is curious why i added stuff like Description, etc. to it: this would allow Blish (or any Repository-Website) to easily show informations regarding a pack.

I would even propose to add a "pack.png" file to the ZIP with some kind of icon for the pack.

@dlamkins
Copy link
Member

dlamkins commented Jun 6, 2019

I've started working on some of this for modules themselves, so this is definitely something we can add to some degree for marker packs. We'd want the manifest format to be in JSON. I just put in the manifest details for modules, here: https://github.com/blish-hud/manifest.json/blob/master/manifest-v1.md

On the side I've begun setting up the infrastructure needed for the module and marker distribution, so this will be important for that! I think we'll need to rename the manifest.json repo to clarify that it is for modules only or it could be restructured to contain the manifests for both modules and markers (and potentially anything else that ends up needing manifests in the future.

I think marker pack dependency could be difficult to manage, but I'd have to spend a little bit more time thinking about it since it would be nice to have to help cut back on a lot of the redundant files found between various packs.

@dlamkins dlamkins transferred this issue from blish-hud/Blish-HUD Aug 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants