No I didn't post a patch, I sent you a link to the clone I have on Github.

So I just moved the token reading code outside of lib. It depends on
Curl_urlfmtdecode for reading tokens that are in
application/x-www-form-urlencoded format (I modified that function as part
of my patch to support both URL encoding and the form variant).

What would be best in curl?

1. Keep the simple token parsing function as a courtesy to users in the
lib (but remove the one that reads from a file)?
2. Have my own decoder in the token parsing code since it's now outside of
the library? (Seems like a lot of duplication).
3. Some other option I haven't thought about. Maybe add a
curl_easy_unescape_form that can be called by anybody, and rely on that?
You may deem this more generic and therefore more useful than the token
reading function.

YA
­­­
Learn about GPT services and architectures on Confluence.
<http://confluence/display/GPT/GPT+Architecture>

On 3/7/13 1:31 AM, "Daniel Stenberg" <daniel_at_haxx.se> wrote:

>On Wed, 6 Mar 2013, Yves Arrouye wrote:
>
>> Did you get a chance to look at my patch for OAuth 2.0 support? I'm
>> interested in pushing this. As I sent to you in email after you
>>requested a
>> path to my clone of curl, I am perfectly willing to move the
>>convenience
>> functions (most or all---see email) out of libcurl and into the tool
>>until
>> someone asks (if ever!) for them.
>
>I don't think I noticed any updated patch after my latest review. Can you
>please re-post them?
>
>--
>
> / daniel.haxx.se
>-------------------------------------------------------------------
>List admin: http://cool.haxx.se/list/listinfo/curl-library
>Etiquette: http://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-03-08