Expansion Development

[hiran]

@timer: might be good to have an up to date status of the current landscape for the session.

Hello, @hiran!
I'm not sure I understood your question )

Then let me refine the question. You continued by 'I can only describe the architecture that I implementing'. This is good. On top of that I am interested at the current state. What you are implementing is not yet done or active, right?

I can only describe the architecture that I implementing as a base/starting option now. CloudFlare D1 is used as a data store for OXP manifests, CloudFlare Worker implements an API available at api.oolite.space for authentication and updating the database, this API used by our site. When the data changes, the Worker generates a plist "on the fly" and uploads the new file via the GitHub API to the repository to the only-static branch, and then it will be available at the same address http://addons.oolite.space/api/1.0/overview.

Sounds great. I'd like to hook in there. Would it be possible for me to provide code that reads from the DB and generates the plist?
I guess some command line application, maybe a docker container would be suitable?

Some automation options can be offered, for example, the developer can place the manifest file in the public access (GitHub or another place), and by one click on the our site - Worker can fetch the manifest file, parse it, and update the data in the database. IMHO, it is possible to fully automate the update process through the mechanics of GitHub hooks, which will react to updating the manifest file in the repo and send signal to Worker.

Actually this is the automation that I'd like to go for. The manifest files are in public locations as part of the OXZ anyway. So the overall plist can be generated based on the OXZs.

Of course, no one cancels the need for a convenient manifest editor (on the site), which can be used to initially create a file (at least).

To some degree I would like to cancel this out. My intention is to have the master information inside the OXZ, which means authors would be pointed to keeping that file up to date. Since that data is retrieved automatically, it will pop up in the plist and a lot of discrepancies are solved, while at the same time the OXZ's manifest.plist can be placed in version control if some author so wishes.

[timer]

Then let me refine the question. You continued by 'I can only describe the architecture that I implementing'. This is good. On top of that I am interested at the current state. What you are implementing is not yet done or active, right?

Here everything is not so fast :(
I checked separately the real work of all parts of this architecture: working with the database, the interaction of the site and the api, the ability to upload a file via api to github. Now I'm transferring/converting the dump of the database that phkb sent me to D1 and then I will check the authentication, then I will rewrite my manifest file generator from perl to javascript.
Unfortunately, everything is very slow due to busy on my job and summer construction work. But I believe that soon I will be able to devote much more time to programming for the Oolite!

Sounds great. I'd like to hook in there. Would it be possible for me to provide code that reads from the DB and generates the plist?
I guess some command line application, maybe a docker container would be suitable?

If we are talking about the call like "give me a plist for a given OXP name" - IMHO there is no problem.

Actually this is the automation that I'd like to go for. The manifest files are in public locations as part of the OXZ anyway. So the overall plist can be generated based on the OXZs.

this means that I approximately correctly understood the direction of your thoughts

To some degree I would like to cancel this out. My intention is to have the master information inside the OXZ, which means authors would be pointed to keeping that file up to date. Since that data is retrieved automatically, it will pop up in the plist and a lot of discrepancies are solved, while at the same time the OXZ's manifest.plist can be placed in version control if some author so wishes.

Ok, the role of the editor as a template generator is not denied?
And updating data in the system in two ways:
1) public URL (most preferred)
2) uploading the manifest file to the site

is it right?

[hiran]

Then let me refine the question. You continued by 'I can only describe the architecture that I implementing'. This is good. On top of that I am interested at the current state. What you are implementing is not yet done or active, right?

Here everything is not so fast
[...]

I am not telling you are too slow. You are trying to juggle a lot of things in the background.
But I am asking what is the status quo we have online right now.

Sounds great. I'd like to hook in there. Would it be possible for me to provide code that reads from the DB and generates the plist?
I guess some command line application, maybe a docker container would be suitable?

If we are talking about the call like "give me a plist for a given OXP name" - IMHO there is no problem.

It would be more a 'give me a plist for a given OXZ download URL'. Once we have that we can wrap it into 'give me the complete catalog for the complete list of download URLs'.

Actually this is the automation that I'd like to go for. The manifest files are in public locations as part of the OXZ anyway. So the overall plist can be generated based on the OXZs.

this means that I approximately correctly understood the direction of your thoughts

To some degree I would like to cancel this out. My intention is to have the master information inside the OXZ, which means authors would be pointed to keeping that file up to date. Since that data is retrieved automatically, it will pop up in the plist and a lot of discrepancies are solved, while at the same time the OXZ's manifest.plist can be placed in version control if some author so wishes.

Ok, the role of the editor as a template generator is not denied?
And updating data in the system in two ways:
1) public URL (most preferred)
2) uploading the manifest file to the site

is it right?

Yes, I am all for 1). At the same time I'd be wondering what 2) would do other than replicate data that may deviate from the information in the OXZ.