Aweplug github and rest-client switch

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Aweplug github and rest-client switch

LightGuard
Administrator
First off, I'm not sure who's all on this list, so I'm adding people I know (and have email addresses) would be interested.

Secondly, Aweplug will house Awestruct extensions for building project websites. The idea is to house all these extensions we've built up while creating Arquillian.org, jdf, and other project sites so we don't end up doing a c&p all the time. The companion project, Awepress, will eventually house all blog related plugins that are currently in Awestruct core.

With that intro done, I'll continue on to $subject. I'm considering pulling out our current GitHub work and replacing it with a proper, and fully complete GitHub API gem. The two currently in the running are


octokit seems to be the most popular of the two in the Ruby community. This helps us not have to rebuild the wheel, and also gives us some new functionality that didn't exist before (oauth tokens, the rest of the api). The downside is that it would include seven additional gems (listed in the gem page, and one transitive dependency). I don't know how many people care that much about this, but some may, hence the email.

The other idea is removing rest-client in favor of faraday. It's built like rack and contains it's own middleware section, including caching! We've hacked up our own caching for rest-client, but having something already baked in would be nice, and it's extensible too. The other plus with faraday is that's actually being developed and released, unlike rest-client which hasn't seen a release in nearly 2 years (looks like development has picked up again though). I think in this instance the pros outweigh the cons of some additional dependencies. What does everyone else think?

--
Reply | Threaded
Open this post in threaded view
|

Re: Aweplug github and rest-client switch

Brian Leathem
Here's my thoughts:

+1 for Aweplug

Why have both Aweplug and Awepress?  I don't see why you need a
separate repo for blog plugins, just put them in Aweplug

Do whatever you think is best for the GitHub API gem (deps aren't a big
deal from my perspective)

REST client - caching sounds good, but again I don't have much feedback
here, as I don't use it (yet)

Brian

On Wed 29 May 2013 05:59:16 PM PDT, Jason Porter wrote:

> First off, I'm not sure who's all on this list, so I'm adding people I
> know (and have email addresses) would be interested.
>
> Secondly, Aweplug will house Awestruct extensions for building project
> websites. The idea is to house all these extensions we've built up
> while creating Arquillian.org, jdf, and other project sites so we
> don't end up doing a c&p all the time. The companion project,
> Awepress, will eventually house all blog related plugins that are
> currently in Awestruct core.
>
> With that intro done, I'll continue on to $subject. I'm considering
> pulling out our current GitHub work and replacing it with a proper,
> and fully complete GitHub API gem. The two currently in the running are
>
> 1. http://rubygems.org/gems/github_api
> 2. http://rubygems.org/gems/octokit
>
> octokit seems to be the most popular of the two in the Ruby community.
> This helps us not have to rebuild the wheel, and also gives us some
> new functionality that didn't exist before (oauth tokens, the rest of
> the api). The downside is that it would include seven additional gems
> (listed in the gem page, and one transitive dependency). I don't know
> how many people care that much about this, but some may, hence the email.
>
> The other idea is removing rest-client in favor of faraday. It's built
> like rack and contains it's own middleware section, including caching!
> We've hacked up our own caching for rest-client, but having something
> already baked in would be nice, and it's extensible too. The other
> plus with faraday is that's actually being developed and released,
> unlike rest-client which hasn't seen a release in nearly 2 years
> (looks like development has picked up again though). I think in this
> instance the pros outweigh the cons of some additional dependencies.
> What does everyone else think?
>
> --
> Jason Porter
> http://en.gravatar.com/lightguardjp



---------------------------------------------------------------------
Archives: http://talk-archive.awestruct.org/
To unsubscribe, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Aweplug github and rest-client switch

LightGuard
Administrator
Inline

Here's my thoughts:

+1 for Aweplug

Why have both Aweplug and Awepress?  I don't see why you need a separate repo for blog plugins, just put them in Aweplug

We have a number of people using Awestruct just for blogs, in fact probably more than are using it for project site creation right now. For those people, and it make it easy for people who want to get started creating a blog with Awestruct it's important to keep it simple and easy (I think the ultimate goal is to make these plugins register themselves with awestruct, then you just configure them and start blogging) for those people. Adding in extra extensions (like JIRA, GitHub, Identities, etc) makes no sense for those people. That's the main reason for keeping them separate.
 
Do whatever you think is best for the GitHub API gem (deps aren't a big deal from my perspective)

REST client - caching sounds good, but again I don't have much feedback here, as I don't use it (yet)

You'll find it very helpful when you because you'll eventually run out of github api calls, or some other service, plus you can determine the caching time so if you're hacking on a site all day you'd only be making those calls once instead of once an hour or every time. Speeds up development time.
 
Brian


On Wed 29 May 2013 05:59:16 PM PDT, Jason Porter wrote:
First off, I'm not sure who's all on this list, so I'm adding people I
know (and have email addresses) would be interested.

Secondly, Aweplug will house Awestruct extensions for building project
websites. The idea is to house all these extensions we've built up
while creating Arquillian.org, jdf, and other project sites so we
don't end up doing a c&p all the time. The companion project,
Awepress, will eventually house all blog related plugins that are
currently in Awestruct core.

With that intro done, I'll continue on to $subject. I'm considering
pulling out our current GitHub work and replacing it with a proper,
and fully complete GitHub API gem. The two currently in the running are

1. http://rubygems.org/gems/github_api
2. http://rubygems.org/gems/octokit

octokit seems to be the most popular of the two in the Ruby community.
This helps us not have to rebuild the wheel, and also gives us some
new functionality that didn't exist before (oauth tokens, the rest of
the api). The downside is that it would include seven additional gems
(listed in the gem page, and one transitive dependency). I don't know
how many people care that much about this, but some may, hence the email.

The other idea is removing rest-client in favor of faraday. It's built
like rack and contains it's own middleware section, including caching!
We've hacked up our own caching for rest-client, but having something
already baked in would be nice, and it's extensible too. The other
plus with faraday is that's actually being developed and released,
unlike rest-client which hasn't seen a release in nearly 2 years
(looks like development has picked up again though). I think in this
instance the pros outweigh the cons of some additional dependencies.
What does everyone else think?

--
Jason Porter
http://en.gravatar.com/lightguardjp





--
Reply | Threaded
Open this post in threaded view
|

Re: Aweplug github and rest-client switch

Gerhard Poul
On Thu, May 30, 2013 at 8:55 PM, Jason Porter <[hidden email]> wrote:
> We have a number of people using Awestruct just for blogs, in fact probably
> more than are using it for project site creation right now. For those
> people, and it make it easy for people who want to get started creating a
> blog with Awestruct it's important to keep it simple and easy (I think the
> ultimate goal is to make these plugins register themselves with awestruct,
> then you just configure them and start blogging) for those people. Adding in
> extra extensions (like JIRA, GitHub, Identities, etc) makes no sense for
> those people. That's the main reason for keeping them separate.

while I do like the name Awepress something like JIRA or GitHub
extensions might be real differentiators for a blogging tool. :-)

---------------------------------------------------------------------
Archives: http://talk-archive.awestruct.org/
To unsubscribe, e-mail: [hidden email]