modularize /on/ #505
Comments
|
👍 |
|
I'm going to take a look at this, this weekend. |
ghost
assigned 
|
Cool. Let's make a milestone out of this and self-assign some tickets out of that. |
|
@lyndsysimon made a solid start on this at PyCon. Not sure where his code is though ... |
|
It's here - I plan to open a pull request to link to these issues today. |
|
I just ended another multi-hour session on this - I'm 70% done with my third rewrite. I think I fully grok how external services should be structured now, though, and I'm still plugging away. There are a lot of layers to peel back that aren't really obvious at first glance. When I'm done, there will be a documented way to add new external service providers with a single file/class, including specifying whether or not the provider is allowed for signing into Gittip. |
|
Awesome! Thank you, Lyndsy, this is an important project with several things dependening on it:
Have you merged master out to your fork/branch? It's moved a lot since PyCon sprints, including the addition of Bitbucket integration under the old way. Should we schedule a hangout this week to review your progress so far? |
|
The problem I'm facing right now is finding enough uninterrupted time to get my heard wrapped around what I'm trying to accomplish, then actually implement. Let me touch base with you again Wednesday. I've got some time lined up tonight and tomorrow to work on it. If you or someone else wants to grab it and run, I'm not going to be offended. |
|
@lyndsysimon what ever came of this? |
|
I ended up getting a job offer after PyCon, and subsequently moved from Arkansas to Virginia :) I'm pretty well settled in now, and should be diving back into the code side of Gittip very shortly. I was hoping to do so by arranging a hackday in Pittsburgh, but that's looking like it will take too long and I need to just get off my duff and do it. If you or someone else wants to take it on, by all means go for it and just post a note here. Otherwise, I promise it's first on my list of non-work-related programming projects. |
|
I believe this is also waiting on #1369. |
|
Continued on #1369. |
@clone1018 and I were talking about this a bit ago. We need to make the
/on/directory easier to extend, so we can add more services fast and easily. I imagine this manifesting as a base class ingittip.elsewherethat we then subclass and use in/on/foobar/. Things on our radar to use as examples when designing this:/on/github/ (individuals and organizations)/on/twitter//on/rubygems/(RubyGems.org integration #223)/on/rubygems/profiles//on/rubygems/gems//on/packagist/(Look into Packagist Support #467)/on/dribbble/(/on/dribbble/ #504)/on/julython/(integrate with Julython #443)This is a bit of a design challenge to find the sweet spot between flexibility and ease of adding new services. Only four services need to be usable for auth: GitHub, Twitter, Google and Facebook. Beyond that we want an infinite number of services that can be connected to a Gittip account. Coderbits actually has a ton of services, e.g. We also have Singly on the radar (#429).
When the third party is explicitly partnering with us (Work for Pie, ThoughtStreams, RubyGems, Julython), then the pattern is to add a "Gittip username" field to the profile on the other site. Until we implement OAuth, #455, users have to manually change their Gittip username on other sites when they change it on Gittip. However, we still want to have
/on/workforpie/endpoints for these services so that people can pledge to people on the third party that aren't on Gittip yet.When the third party is not an explicit partner, we want the
/on/twitter/endpoint with the option to connect, and then we'll scab the button onto the other site via the browser extension.The text was updated successfully, but these errors were encountered: