Poll

Should I add increased BLID gathering abilities to Support_Updater and make a public, searchable list of BLIDs and names?

Yes
34 (81%)
No
8 (19%)

Total Members Voted: 42

Author Topic: Support_Updater  (Read 54539 times)

Assuming that's right, the whole system should be functional now. Existing add-ons still need a script to pass over them and generate their version.txt files, but any new files and updates will show up in the repo and have the version.txt in the zip.

Having a single large repository may conversely also be a little taxing to generate as there could be a lot of database calls.

How are these mod IDs assigned? Is there any sort of convention to it? Should it be one I generate or should it relate to the add-on name?

edit: Eh?

You should only need a single database call: http://stackoverflow.com/questions/20472794/mysql-selecting-multiple-rows-that-match-array-of-ids

Mod IDs can be any integer you'd like. (just make sure it matches the one in the version.txt file) That repo looks good. Just add all the channel and version info now and you're set.
« Last Edit: June 15, 2015, 07:35:18 PM by Greek2me »

You should only need a single database call: http://stackoverflow.com/questions/20472794/mysql-selecting-multiple-rows-that-match-array-of-ids

Mod IDs can be any integer you'd like. (just make sure it matches the one in the version.txt file) That repo looks good. Just add all the channel and version info now and you're set.
The way I have the database structured, I have an add-on table, update table, and a file table. The add-on table points to different files in the file table (for each branch), and each update is kept as a separate entry in it's table. Either way, how it is now is fine.

The channel and version info is available for any add-on that has had an update.

Version 0.8, which adds JSON repository support, has been released!

Any chance you could make it so you can update each addon individually?

Also, I need a little help with this...

Any chance you could make it so you can update each addon individually?

Also, I need a little help with this...

That's what this does. If you don't quite understand the readme, I'd recommend that you use a managed add-on hosting solution like Blockland  Glass.

What are your thoughts on implementing fallback repositories? If you read the Blockland Glass topic, I'm moving files to amazon for redundancy, and I'd like to be able to maybe do a nightly upload of a full, BLG-wide JSON repo to it, just incase the server ever goes down. On top of that, I'd like to be able to list 'upstream' repositories as one of the back-ups.

My thinking is that if the service ever goes down, I don't want to leave a whole bunch of people headless like RTB did.

So maybe have them by priority based on the order listed? (example for one of your mods, assuming you set up the upstream repo and what-not)
Code: [Select]
...
repository http://blocklandglass.com/api/support_updater/repo.php
repository http://s3.amazonaws.com/blg-cdn/repo.txt
repository http://mods.greek2me.us/repository.txt
...
although there would also have to be some way to define the format of each independently..
« Last Edit: June 24, 2015, 10:31:16 AM by Scout31 »

Would it be acceptable for the backup repositories to require the same format as the main repository?

I mean, just for example, Glass is all in JSON. Yours is all TML. If it were to be set to JSON, then when it came to fall back to yours, it wouldn't be interpreting it correctly. I could require all upstream repositories to be JSON, but that limits functionality and simplicity.

I would suggest the following:
Code: [Select]
repository http://cdn.blocklandglass.com/repo.txt JSON

However I fear that could break backwards compatibility. I haven't looked closely enough at the bitbucket to see if it stictly checks the second field/word alone, or just the rest of the line.

I could easily do that and maintain compatibility. If I go that route i will also deprecate the 'format' flag.

Well, if you decide to implement it, let me know. I'd love the redundancy.

If you want an idea of where this add-on is going, take a look at the issue tracker: https://bitbucket.org/Greek2me/support_updater/issues?status=new&status=open

updaterInterfaceDisplay doesn't appear to be called. I have updates available, but the Glass update gui (using your pull request) isn't being pushed at all.

updaterInterfaceDisplay doesn't appear to be called. I have updates available, but the Glass update gui (using your pull request) isn't being pushed at all.

Apologies, I forgot about that. You should push the GUI (if it hasn't been already) in updaterInterfacePustuffem.

Does using the raw pastebin still work instead of using GitHub & bitbucket?