Access script source without triggering install count

[sizzlemctwizzle]

It might be useful to allow access to the script source without triggering the install count. This would discourage people from artificially inflating the install count if they need access to the source for some other reason. I'm weary of people using this instead of uploading their script as a library, but at least this way it won't inflate their install count.

Unrelated thought: we really need to implement cache control for library source (since TM is downloading the source every time its internal cache expires). This is causing more bandwidth usage than it should.

[Zren]

I took a look at greasyfork's implementation on this as they have awesome looking install counts/graphs. They log every hit up to 15 by ip address.

[sizzlemctwizzle]

I consider statistics gathering a low priority at this point (it mostly benefits authors, which is a minority of users), but if working on that interests anyone, I'd be glad to have it.

[Martii]

TM is downloading the source every time its internal cache expires

Last check was 8 hours max that Chrome/Chromium would allow server side... e.g. I set my cache to 30 days and it still downloaded every 8 hours regardless of setting... but that was a few months back... perhaps they have adhered to web standards?

It might be useful to allow access to the script source without triggering the install count.

Yes it would. :) Is the "raw url" going to omit user.js by default with your commit? I'd rather not trigger any user.js engine installer on the URL at all and set the content type to text/plain or other non-application/javascript (I'm not seeing anything like this in the commit so possibly a -1 vote for the moment but with a possible flip if implemented with some minimal safeguards and clearer definitions) EDIT: Another option is to use a header to request script source but no install count... similar to x-userscript-meta but this could be non-symmetrical with that feature.

[sizzlemctwizzle]

Last check was 8 hours max that Chrome/Chromium would allow server side...

Better than serving it up every time like we currently do.

set the content type to text/plain or other non-application/javascript

I guess we could use .js instead of .user.js since it's under /src/scripts/ anyway. I don't see a problem with serving it up with a javascript content type.

use a header to request script source but no install count

It'd probably be ignored. Plus I like the symmetry of serving up the raw source similar to libraries.

[Martii]

I don't see a problem with serving it up with a javascript content type.

User.js with the install button on every page using the incorrect url and not incrementing the install count and messing up automatic updating in each user.js engine with the incorrect url. e.g. the flip side of this coin... the only reason I personally would need this feature is to do a scan of the source code from the homepage I think. If we serve the content at text/html that should prevent accidental installations too, in between pre and/or code block and give a bonus perk of being xhtml compliant so no need to convert in user.js.

[sizzlemctwizzle]

User.js with the install button on every page using the incorrect url and not incrementing the install count.

You mean someone could write a script to do this? GM accepts any url that ends in .user.js and is served as any content type except text/html. But changing the url ending to .js would prevent this.

[Martii]

You mean someone could write a script to do this?

Yes.

GM accepts any url that ends in .user.js and is served as any content type except text/html.

Correct unless someone adds a #.user.js to the end in which we are back to a bug... so best to do the Content-Type of text/html with the code cased in some simple tags and optionally remove the .user.js to eliminate any doubt, and future bug reports both here and on the user.js engines for this "special" route you are building to prevent installation counts.

[Martii]

Also if you are thinking about this new route to prevent installation counts with actual script source with the header of x-userscripts-meta for updates we'll need to detect first time install and ping the count once (not sure if this is technically possible at our tier btw)... but the GMU via AOU is going to try the installation path first with .meta.js and the header ... so authors will need to use @updateURL and @installURL in those uses cases or have an account setting to change the default per script author. A lot of the "bigger picture" deals with who wants all increments versus new installs.

[Martii]

Tested at local dev script with source url of this... did trigger GM installation dialog but doesn't appear to increment so +1 on the advertised feature. :)