OR Route Downloader -> Providers configuration
#11
Posted 24 February 2024 - 03:25 PM
It's not difficult for us or other sites to publish a replacement JSON file for those who want our content. The Indian community will certainly do that.
#12
Posted 24 February 2024 - 06:36 PM
#13
Posted 24 February 2024 - 07:04 PM
#14
Posted 24 February 2024 - 08:47 PM
When I look at the non-Git references in the content/routes.json file, it's going to the public pages for these routes either on Peter Newell's site, Trainsimulations.net's site.
There's nothing explicit in the JSON which says what to download...
Is that because this is just a placeholder, or is this feature really going to simply be a curated list of favorites?...
Maybe Siebren or one of the other developers who've been working on this can explain in a little more detail on the specifics.
#15
Posted 24 February 2024 - 09:47 PM
eolesen, on 24 February 2024 - 08:47 PM, said:
There's nothing explicit in the JSON which says what to download...
Is that because this is just a placeholder, or is this feature really going to simply be a curated list of favorites?...
Jack, I think you've done well trying to facilitate this conversation, but I'm still a bit lost at the intent here.
Are you trying to understand my intent with this conversation, or the intent of the route downloader?
As for the routes.json file:
Siebren told me that the routes.json file was already in use for some portion of the openrails website.
As such, it contains links to some routes that are displayed on the openrails website, but not displayed in the openrails downloader.
This is the criteria that decides if a route is presented in the downloader:
if (url.EndsWith(".git") || url.EndsWith(".zip"))
The route entries you inspected by Peter and Trainsimulations don't end with .git or .zip, so they get skipped in the downloader.
#16
Posted 28 February 2024 - 01:30 PM
Jack@Elvas, on 24 February 2024 - 07:04 PM, said:
That could be a problem for boards like this Jack. Simply put, once the location is revealed doesn't that mean anybody could get to it? By and large that runs counter to most boards intent, certainly against the intent of any payware location. If a person has to log into that board then the matter is solved, indeed this board's software substitutes a random string pointing to a temporary location instead of the real one. But what if the files are simply a location on some disk? How would payment be collected for payware files?
Perhaps these matters are resolved already but if not they're a problem.
#17
Posted 28 February 2024 - 02:08 PM
cjakeman, on 24 February 2024 - 11:48 AM, said:
Another issue is copyright. If Open Rails can pull in content from anywhere (including content which is illegally copied from the creator), does that make Open Rails responsible for breaking copyright?
Naturally it is complex. In the US the relevant legislation goes by the initials DMCA. AFAIK respect for this legislation is given by most countries. AFAIK it has two relevant clauses:
1: The person doing the downloading does not avoid criminal liability by asserted he had no idea/knowledge the material he got was copyrighted and downloaded in violation of the law. This is really unusual because bad intent is usually a perquisite for charging someone with a crime.
OTOH
2) service providers will not be held liable for the actions of anyone violating the DMCA is they adhere to take down requests. This usually applies to ISPs but can apply to ordinary sites who also comply with the take down requirements. This site did so in more than one case and our actions were acceptable.
What I think this means is this: So long as Github and the individuals maintaining this software do what they are supposed to do WRT it should be a non-issue for the OR team.
Last thought: Copyright depends on creativity; virtually all of the rolling stock we use cannot be creative because it is simply a copy of a real world object (Meshworks v. Toyota). It took skill, knowledge, and time but not creativity (Thomas the Tank Engine is creative, a model of a SD-40-2 is not). This means an .s file, by itself (i.e., no skins), is not protected by copyright. Lists of data are not creative (e.g., a phone book), so a single w. file is probably not protected. All of them together might be.
Did I say complex? You betcha.
#18
Posted 28 February 2024 - 04:58 PM
Genma Saotome, on 28 February 2024 - 01:30 PM, said:
Perhaps these matters are resolved already but if not they're a problem.
You are correct, that in the current form, this system would only be good for truly public and free routes.
Someone intending to sell routes, or put them behind a membership would not be able to make use of the system as it stands today.
This is one of the key issues I hope to solve by introducing the concept of "providers" - as each provider would have a mechanism for some form of authentication for download.
#19
Posted 29 February 2024 - 02:49 AM
Github is now established as having many advantages for routebuilders ( providers) . The facility of WIP continuous development and allowing several collabotators, being very valuable.
There maybe a snag. with ,zip in Git hub download. If the code is invoking Github .zip download I find that this is unreliable and often misses files from the download. Possibly the ..zip is not pointing at the current repository but at a previous stage such as the misleading "latest version" label.
Users never report problems with a faulty download . I think they just give up
Download from the Github app "desktop" is reliable, but I think users are reluctant to use this even though it also allows easy updates.
So i suggest providers test the validity of the download. Rick
"if(url.EndsWith(".git")|| url.EndsWith(".zip"))
#20
Posted 29 February 2024 - 06:23 AM
GitHub besieged by millions of malicious repositories in ongoing attack
This is where I begin to worry, not what I would do, but some unsuspecting person not really grasping the possible dangers.
Steve