Move default comments to external sources

[alerque]

After reading the chatter the other day about comment data and import/export, I've been thinking our arrangement could be something like this:

• The userscript/extension source code would have no default comment data whatsoever.
• A repository (could be a secondary repo, the main one or a branch) would have the default comment data in json or text format.
  • A data file per site URL would make it easy for misc contributors from other sites to get good site specific data into as many hands as possible.
  • A fallback URL would have generic data to be loaded in any site that does not have a custom data set contributed.
• The first time the popup runs on a new site it would detect that the localStorage has no default comment data for that site.
  • A popup would prompt the user to import data with an "import from URL" option pre-filled out with the relevant URL (but editable) and a "or paste data here" field to allow for users mucking around in their data manually or copying from a meta site post.
• For sites that already have data in localStorage, a an "edit data" link would take the user back to the import form where they can either refresh from the URL or edit/paste in a new data set.

How does that arrangement scan?

[IzzySoft]

I'd leave some site-wide (generic) messages within the script just in case for

• link goes down for some reason
• network issues prevent connecting it
• users behind a restrictive firewall not being able to access it

[alerque]

Not a bad idea. That could be in lieu of my fallback URL above. I would still want to see the prompt on first run (per site) to "import site comments" with a pre-filled out URL and "load generic data" (and optionally edit in a textarea) as the secondary method to populate localStorage to encourage use of per-site data sets. If that is silently loaded on all sites by default the awareness that per-site data is even available goes way down.

[IzzySoft]

Agreed. Was not intended as "replacement", just as, say, additional fall-back.

So when pulled from the "new sources", would that a) merge with existing entries (I doubt that's easily implemented), b) add to them (would cause dupes), or c) replace (user would lose his own customizations)? As a) most likely won't be the case, user needs an option to decide whether to (always) blindly replace ("trust the source"), or do a manual merge. That's most likely what your last item with "edit/paste" is referring to. With large sets (local and remote), that might get a little tricky.

[Benjol]

Some questions with request to this feature:

• how would the script determine the url for the given site: a lookup table?
• should we adapt the 'get from remote' to only look once per day?
• I think that we need some way to also tell users who are already using their own remote that we have created a centralised one, but at the same time, we don't want to nag them about it on every new version (and every different site!)

[alerque]

@Benjol In order:

• You can see a working prototype how I imagined the URL working in 66fd72d. Missing from that prototype is an if_exists() check of some sort so this only works for sites that have custom data (with will almost certainly not be all of them). Still, the idea of using a pre-defined base URL where the JSON data is expected plus a segment with the site domain name to pick the file seems workable.
• Yes, absolutely.
• I agree. I think per-site is ok but ONLY for sites that actually HAVE customized data in a central repo. If no file exists we shouldn't bother prompting them and put off the check for another day (or week). If they have customized local data and dismiss the prompt about a new central data set, I agree they should not be nagged again, but if there should be a way to get back there if they look for it. The remote URL for example can still be pre-populated with the central repo.

[oliversalzburg]

I like @alerque approach with the hostname being part of the URL. That seems pretty flexible.

Maybe the user should be allowed to set an alternative base URL. Then the user could just override the files he wants in their own repo. And if no appropriate document is found at the user-specified location, fall back to the default repository.

[Benjol]

Further thought: I think if the user customises any comments, the auto-update should be automatically switched off (perhaps with a warning). As it stands, the auto-update fills the localStorage, which suits us if we only want to check once per day.

[alerque]

I'm down with that @Benjol.

Having an alternate base_url seems like more trouble than it's worth @oliversalzburg. We don't have a persistent way to set that across sites anyway, and the most likely use case is that the user is interested in a site they have customized, in with case having them enter the remote URL for each site seems reasonable and they can always fork this or compile their own version with a different base URL if our comment sets aren't satisfactorily maintained. I don't know of a way to have a user-entered base-url persist across sites anyway.

[oliversalzburg]

Fair enough. I don't really have an understanding of that part of the script anyway :)