Hi,

On Don 20.04.2006 11:12, Daniel Stenberg wrote:
>On Thu, 20 Apr 2006, Alexander Lazic wrote:
>
>>Yep i have started to look into the main.c and some other parts, what
>>I have seen is that this changes are a mayor code && design change.
>
>Well, yes but the tool is pretty simple as it is now so cramming in
>advanced fetures in a simple loop like today is of course bound to
>require changes!
>
>Given some more thoughts and planning, I would actually think that the
>curl code would benefit from such a little reorg.

Ok, step by step ;-)

>>curl url1 : --serialize -H $HEADER_FROM_PREVIOUS_CALL url2
>>curl url1 : --serialize -d $FORM_FIELD:formvalue url2
>>curl url1 : --serialize -d `get_form_field`:formvalue url2
>
>I read you. These are mighty advanced features indeed. It'll take a
>good deal of thinking to define how these would work and be used.

;-)

>Personally, I don't see the benefit of trying to remove all external
>scripting by adding every possible need to the tool itself. It just
>makes the curl tool (and code) larger and more complex, and it will
>NEVER be able to completely replace external scripting needs anyway.

Full ack, but a little bit more is more ;-)

>But I'm certainly open for discussions and ideas.

Thanx for this open thinking ;-)

>I could very well imagine building a 'curlboo' (I picked a silly name
>to reflect that the name itself doesn't matter) tool that would have
>all curl's features and an additional bunch, just to keep curl somewhat
>simple and yet offer complicated things in the new tool. They would of
>course share most of the grunt code.

Hm wy not, such as a little and a big brother of libcurl ;-)

regards

Alex
Received on 2006-04-20