Documenting stacks/platforms instead of individual domains

[stuartpb]

Right now, "platform" is just a simple field. However, it's entirely feasible that these profiles could hold detailed platform info (on the order of BuiltWith.com's info). Also, it's likely that platforms could be more complex than just 1:1 name matching.

I propose that platform is redefined to something like platform.application.name and platform.application.version, where "applications" is a new set (next to "profiles") where versions, with their defaults, are provided as an array.

Moreover, there's probably a need for some kind of "mount path" data for apps - keys they use as the basis of their URL defaults. This needs further consideration.

[stuartpb]

There's also the matter of reused auth components like devise.

[stuartpb]

I think for 0.1.0 it's sufficient to just replace all the current "platform" values with "platform.application.name", considering that we're pretty far from going much further with it right now anyway. This just moves the data we currently have to a position where it's less likely to need to move in the event that an ecosystem spontaneously springs up around it down the line.

[stuartpb]

I think https://github.com/opensets/domainprofiles/blob/pebble/profiles/com/getpebble.yaml looks really similar to a lot of sites I've profiled lately: I should check for other sites with the same length rules, or the same route suffixes. I think this is the current shipping user account UI for Rails.

[stuartpb]

Actually, the simpler model seems to me to be an array of... let's say an array of names, with different names referring to different layers of platform rule to look up (like if they're using Auth0 with Rails). Later named platforms overwrite values of earlier ones, with the final layer being the profile itself.

And so if PHPBB version 2 and PHPBB version 3 have different rules for some things, they'd be defined as phpbb2 and phpbb3: if they don't differ, there's no significant reason to distinguish them (leave the complex platform breakdown to BuiltWith).

[stuartpb]

What about mount path variables? Maybe "platform" should have a "stack" array (structured as above, as a list of layers) and a "config" object.

[stuartpb]

And platform profiles should be "stacklayers" (which might go next to domains in profiles which might be flat after #44)?

[stuartpb]

How deep should the overwrites go? Rules seem like they should be a wholesale clobber.

[stuartpb]

sxsw.com uses the Rails thing.

[stuartpb]

Figuring out how to detect platform... I think, for now, it's just going to be a matter of going to a site and duck-typing it - if it looks like it matches all the stack's features, it's that stack.

[stuartpb]

It looks like this is like #6 in that we don't have a lot of data for it now, and figuring out how that data should look is going to take a lot more thought, on structuring, discovering, and using this data (which are entwined concerns).

I think, for now (and going into 0.1.0), the solution is just going to have to be to copy-paste, and for discussions of stack (including hunches or evidence as to what a site's stack is) to be figured out in a pull request's comments thread, with labels on any PR/issue that includes discussion about what a site's stack is. we don't flood this issue with discussion about specific profiles (any more than it already is), and once a clear mechanism for exposing (and integrating, tooling-wise?) stack data has been figured out, we can go back and re-check those discussions for leads when forming the fully-usable data for them. There's probably going to have to be a #56-type pull request for removing the current, under-discussed platform entries currently in the data; that might end up being where the central "this is what this stack looks like" discussion might go. (Or it might go in the wiki. I don't know. I should be asleep.)

[stuartpb]

Right now we have 4 profiles using a "platform" field (that's 3 more than were using profile.fields, but still not much), of which 2 are "zendesk", one is "mediawiki" (and it's not Wikimedia), and one is "virtuemart" (which I've never seen in another place where it would be applicable). I think those can be pulled out for later reference if applicable. (And I just checked - one of those domains has lapsed, so its profile is no longer relevant at all. RIP, dogeco.in, and your MediaWiki-based characteristics.)

[stuartpb]

Actually, noting stack information converges kind of well with the pull requests that'll be generated in solving #19.

[stuartpb]

Now that this has been removed from the spec with a more workable plan going forward, I'm kicking further consideration to future (ie. unblocking v0.1.0) on this issue, like I did #6.

[stuartpb]

Continuing in opws/opws-schemata#3