Next moves


Archiloque <code@...>
 

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
- 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.
- 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.
- 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?

Regards

A.


Nicholas Wieland <ngw@...>
 

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


Archiloque <code@...>
 

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.


Nicholas Wieland <ngw@...>
 

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


Nicholas Wieland <ngw@...>
 

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


Adam Wiggins <adam@...>
 

On Thu, Dec 17, 2009 at 2:26 PM, Archiloque <code@...> 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


code@...
 

- 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.