Re: [rest.client] Next moves
- From:
- Nicholas Wieland
- Date:
- 2009-12-18 @ 20:28
On Dec 17, 2009, at 11:26 PM, Archiloque wrote:
> Hi,
>
> A few words on the next moves on rest-client.
>
> Adam has (with great success) created and maintained the library
> untill now but can't dedicate enough time for it, so I'm working to
> replace him as maintainer.
>
> My goals being:
> - no full rewrite: the code is mature and used by projects and other
> libraries. As much as possible changes should not break existing API
> or code
I second this. I prefer to refactor minor parts.
> - integrate features developped on forked versions (the number of
> forks is really high, and for the moment users may have to sacrifice a
> feature for another depending on the fork they choose which is a
> really bad situation from my point of view).
> - add some documentation for advanced usages and some unit tests
> - not only work on the code but also help the community (this maling
> list for example)
>
> Thanks to Adam for trusting me, I hope I'll do some good work
>
> ####
>
> Now I have some questions if you can spare me a few minutes:
> - beside taps and couchrest, do you now any other largely used
> projects that rely on rest-client ? The idea is to use their unit
> tests as integration tests for rest-client to be sure I don't
> accidently break an API.
My plan is to integrate it with the OAuth gem (when rest-client is
available) to permit file uploads to the OAuth gem. Of course, I need to
make file uploads work on rest-client before :p
On the matter, does someon know of any working forks of rest-client with
this part implemented ? I forked from
http://github.com/francois/rest-client
> - the project have no dependency for the moment, from my java
> experience I think it may be considered a good feature as it means no
> conflict risk, but is it as valuable in ruby as in java ? I thought
> about it because the partial list of mime types in payload may be
> replaced by the mime-types gems.
I never had a conflict in my life with gems, as far as I remember.
> - a more complicated one: the tab indentation. As far as I know, if in
> a distant future I change the code indentation to spaces instead of
> tabs, it will be a pain for all forkers when they'll want to integrate
> any change done after it, as they'll have to apply the change to their
> code. On the other side, the current indentation is making (a little)
> harder to work on the project, and can make external code integration
> more difficult when people start their work by reformating the
> existing code. Is there a trick to solve this problem or do you have
> some experience on this subject that you could share?
Well, I don't think it's good to keep tabs in the code, spaces are more or
less a de facto standard - my editor converts everything automatically.
I also think that it's more likely that the project has new forks instead
of people to use old ones.
At least, they fix the tab problem just once, while everybody who forks
now has to care about tabs.
ngw
Re: [rest.client] Next moves
- From:
- Archiloque
- Date:
- 2009-12-19 @ 19:58
>> Now I have some questions if you can spare me a few minutes:
>> - beside taps and couchrest, do you now any other largely used
>> projects that rely on rest-client ? The idea is to use their unit
>> tests as integration tests for rest-client to be sure I don't
>> accidently break an API.
>
> My plan is to integrate it with the OAuth gem (when rest-client is
> available) to permit file uploads to the OAuth gem. Of course, I
> need to make file uploads work on rest-client before :p
> On the matter, does someon know of any working forks of rest-client
> with this part implemented ? I forked from
http://github.com/francois/rest-client
It's the fork I plan to intregrate first as I use it myself.
>> - a more complicated one: the tab indentation. As far as I know, if
>> in
>> a distant future I change the code indentation to spaces instead of
>> tabs, it will be a pain for all forkers when they'll want to
>> integrate
>> any change done after it, as they'll have to apply the change to
>> their
>> code. On the other side, the current indentation is making (a little)
>> harder to work on the project, and can make external code integration
>> more difficult when people start their work by reformating the
>> existing code. Is there a trick to solve this problem or do you have
>> some experience on this subject that you could share?
>
> Well, I don't think it's good to keep tabs in the code, spaces are
> more or less a de facto standard - my editor converts everything
> automatically.
> I also think that it's more likely that the project has new forks
> instead of people to use old ones.
> At least, they fix the tab problem just once, while everybody who
> forks now has to care about tabs.
Good point, I think I'll reformat de code as soon as external features
integration has been done.
A.
Re: [rest.client] Next moves
- From:
- Nicholas Wieland
- Date:
- 2009-12-20 @ 20:25
On Dec 19, 2009, at 8:58 PM, Archiloque wrote:
>
>>> Now I have some questions if you can spare me a few minutes:
>>> - beside taps and couchrest, do you now any other largely used
>>> projects that rely on rest-client ? The idea is to use their unit
>>> tests as integration tests for rest-client to be sure I don't
>>> accidently break an API.
>>
>> My plan is to integrate it with the OAuth gem (when rest-client is
>> available) to permit file uploads to the OAuth gem. Of course, I
>> need to make file uploads work on rest-client before :p
>> On the matter, does someon know of any working forks of rest-client
>> with this part implemented ? I forked from
http://github.com/francois/rest-client
>
> It's the fork I plan to intregrate first as I use it myself.
Nice, so I broke something, even if all specs pass.
I will start from the beginning and leave tabs.
ngw
Re: [rest.client] Next moves
- From:
- Nicholas Wieland
- Date:
- 2009-12-22 @ 15:23
On Dec 20, 2009, at 9:25 PM, Nicholas Wieland wrote:
> On Dec 19, 2009, at 8:58 PM, Archiloque wrote:
>
>>
>>>> Now I have some questions if you can spare me a few minutes:
>>>> - beside taps and couchrest, do you now any other largely used
>>>> projects that rely on rest-client ? The idea is to use their unit
>>>> tests as integration tests for rest-client to be sure I don't
>>>> accidently break an API.
>>>
>>> My plan is to integrate it with the OAuth gem (when rest-client is
>>> available) to permit file uploads to the OAuth gem. Of course, I
>>> need to make file uploads work on rest-client before :p
>>> On the matter, does someon know of any working forks of rest-client
>>> with this part implemented ? I forked from
http://github.com/francois/rest-client
>>
>> It's the fork I plan to intregrate first as I use it myself.
>
> Nice, so I broke something, even if all specs pass.
>
> I will start from the beginning and leave tabs.
Ok, I didn't broke anything ... Unfortunately Francois' fork doesn't
support hash of hashes as parameters:
def build_stream(params)
@stream = StringIO.new(params.map do |k,v|
"#{escape(k)}=#{escape(v)}"
end.join("&"))
@stream.seek(0)
end
Will try to fix tomorrow, but it might take some time.
ngw
Re: [rest.client] Next moves
- From:
- Adam Wiggins
- Date:
- 2009-12-23 @ 05:47
On Thu, Dec 17, 2009 at 2:26 PM, Archiloque <code@archiloque.net> wrote:
> - beside taps and couchrest, do you now any other largely used
> projects that rely on rest-client ? The idea is to use their unit
> tests as integration tests for rest-client to be sure I don't
> accidently break an API.
Offhand the one I'd be concerned about is:
http://github.com/heroku/heroku
I'm not sure if unit tests will work - unit tests are supposed to stub
out calls to remote services, which is the whole purpose of
restclient. That's what makes this upgrade challenging. What you did
with taps - that is, submit a patch to lock to the current version of
restclient - is probably the safest thing. (Gem dependencies should
always lock to a particular version - I've been bad about that in the
past, like a lot of people.)
> - the project have no dependency for the moment, from my java
> experience I think it may be considered a good feature as it means no
> conflict risk, but is it as valuable in ruby as in java ? I thought
> about it because the partial list of mime types in payload may be
> replaced by the mime-types gems.
Fewer dependencies is better, but I think that would be a good
addition. I've long wanted a feature like this:
RestClient.post "http://example.com/resource", { 'x' => 1 }.to_json,
:content_type => :json, :accept => :json
> - a more complicated one: the tab indentation.
I like tabs, but I'm fairly alone in that in the Ruby world. Feel
free to switch it over to spaces - I think you're right that that will
encourage more contributions over the longer term.
Adam
Re: [rest.client] Next moves
- From:
-
- Date:
- 2009-12-23 @ 08:05
>> - beside taps and couchrest, do you now any other largely used
>> projects that rely on rest-client ? The idea is to use their unit
>> tests as integration tests for rest-client to be sure I don't
>> accidently break an API.
>
> Offhand the one I'd be concerned about is:
>
> http://github.com/heroku/heroku
>
> I'm not sure if unit tests will work - unit tests are supposed to stub
> out calls to remote services, which is the whole purpose of
> restclient. That's what makes this upgrade challenging. What you did
> with taps - that is, submit a patch to lock to the current version of
> restclient - is probably the safest thing. (Gem dependencies should
> always lock to a particular version - I've been bad about that in the
> past, like a lot of people.)
If you talk about
http://github.com/archiloque/heroku/commit/a99c9f7f9d1dd6acd48aee2991a2b0cb8503f6a9
it's a patch that makes heroku having the same gem version requirements as
taps (the bug happens when heroku loads a rest-client version that isn't
allowed by taps then makes a bad exception handling) so I didn't add a new
lock but only made an existing lock explicit
And:
- it would be nice to accept my patch in heroku because I won't be able to
ship a 1.1.0 rest-client version without it
- heroku is on my tests list (and as I use heroku myself you can be sure
I'll check it), I think I'll add a document that lists the tested gems to
the repository
- taps works perfectly well with the multipart code
>> - the project have no dependency for the moment, from my java
>> experience I think it may be considered a good feature as it means no
>> conflict risk, but is it as valuable in ruby as in java ? I thought
>> about it because the partial list of mime types in payload may be
>> replaced by the mime-types gems.
>
> Fewer dependencies is better, but I think that would be a good
> addition. I've long wanted a feature like this:
>
> RestClient.post "http://example.com/resource", { 'x' => 1 }.to_json,
> :content_type => :json, :accept => :json
It would be nice as the code is clears and matches the rails way. I've
enabled the issue tracking on my fork so could you create an issue about
it ?
Talking about issues, I had a look at the issues on your repo and some of
them seems legit so I'll have a look at them.
> I like tabs, but I'm fairly alone in that in the Ruby world. Feel
> free to switch it over to spaces - I think you're right that that will
> encourage more contributions over the longer term.
So this the proposed plan
- next version: francois's multipart code
- n + 1 : tabs to space
- n + x : existing issues on github & docs & new thingies
Nicholas is working on an oauth patch, as the code should not be intrusive
it may be included in the n version
A.