twolfson
commented
8 years ago First off, thanks for raising this issue. It's good that we are finally trying to unify our efforts with respect to handling the brittle DOM of Google Music.
I will talk to each about points individually.
Fragmented code
With respect to using a common API but it not encompassing the entirety of your app, this is kind of like chasing The Holy Grail. We are different applications that have some overlap but are not duplicates of each other.
For example, Radiant has theming and hides Google notification whereas I choose to avoid the potential brittle-ness and keep the UI more/less the same.
That being said, there is definitely some more room to help each other out (as you say -- last.fm integration would be nice). However, I don't think an overarching framework is the way to do that. Instead, I would prefer more one-off repos (so I can only download/import what I need) and maybe a larger library that allows you to bind them all at once (if that floats your boat).
Common ownership
I'm all for having common ownership. We have been wanting that for a long while (radiant-player/radiant-player-mac#252).
I think that the argument about something breaking without a quick turnaround is a bit of a strawman. When Google Music shifted to Material, we updated our integration within 24 hours.
While I see your concern, I also don't want to maintain a repository that is being cowboy committed (i.e. without a code review process). My suggestion would be something like:
- Issue appears
- Person A triages it and writes fix
- Person A opens PR
- If person B sees the PR and is available
- Person B performs code review
- Otherwisei f person B sees the PR but is unavailable to thoroughly review, person B gives ETA
- If ETA is tolerable, then person A waits for full review
- Otherwise if person A doesn't hear from anyone within reasonable time (e.g. 24 hours)
- Person A can cowboy land changes
I should also mention that npm supports referencing git URLs. This means we can publish our application with a non-published google-music.js.
https://docs.npmjs.com/files/package.json#dependencies
https://docs.npmjs.com/files/package.json#git-urls-as-dependencies
Fixes rely on users updating their applications
While I understand your concern, I think this is attempting to solve an effect of a deeper problem. There's usually a reason for people refusing to update (e.g. nothing telling them about new update, not willing to take time to update). For that, I would suggest finding out why and maybe adopting an auto-updater (e.g. Squirrel -- what's used by Electron):
Additionally, if we were to always point our JS to master, then it will only work until we introducing a breaking change. At some point, our API might change; we might rename a method or change a function signature for ease of use or consistency. We don't want to code ourselves into a corner which will break everyone =/
One alternative would be to have major/minor branches as part of updates (e.g. for a release like 1.2.3, we would update a branch 1.x.x and 1.2.x which point to the same version). That could be used with http://rawgit.com/. I use the same technique on gratipay-badge:
https://github.com/gratipay/gratipay-badge
tl;dr
To summarize everything:
- Open to moving to a GitHub organization as long as we have a conservative code review process in place
- Opposed to making a catch-all JS repo for all our features, would prefer targeted one-off repos (e.g. low-level bindings to page, library for theming, library for last.fm)
- Opposed to always pointing to
masterand personally prefer checking releases by hand but open to adding major/minor branches
jacobwgillespie
chrismou
MarshallOfSound
Copy paste from the message I sent a while back
Hey guys, I added both of you to this group as I think we are all "stakeholders" (if that is the correct word to use), in the potential for an expanded Google Play Music JS Framework that extends on what @twolfson has already done in his Google Music node package.
I have recently made a branch on my player that changes all my JS to use the Google Music node package, but I realized while testing that what I was doing had a few issues a) My code was still fragmented, some of it used this marvelous API. Whilst the rest was doing everything manually with obscure, unrecognizable selectors b) I had no control over this framework, if something broke I couldn't push out a fix in a few hours I would have to wait for either @twolfson to fix it or submit a PR and hope it gets merged c) These fixes still relied on the user updating their application, if for whatever reason they decided not too (some users are stubborn like that) they will not get the fixes...
I would like to propose the following We should either fork or move the Google Music node repository into a space where people who use it (Me, Radiant Player, Electron Player, Etc.) will have contributor rights to allow one of us to push fixes ASAP. This will allow changes to go out much quicker as it will take only one of us to fix everyone's applications Instead of depending upon statically released JS files we should depend on a CDN? Or the latest github release? so that updates to this framework, can be pushed independently of a version bump on our players This proposed framework should maintain the existing functionality of the current Google Music node package but should also have add on packages that allow theming support (I have some funky JS in my repo at the moment that does this) and other things like possibly a central last.fm intergration library? What do you guys think of this proposal?
Tagging relevant parties @twolfson @jacobwgillespie @chrismou