<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 23/03/2013 13:58, Samuel Gougeon a
      écrit :<br>
    </div>
    <blockquote cite="mid:514DA6E1.6070808@free.fr" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">Hello Sylvestre,<br>
        <br>
        Le 24/01/2013 18:14, Sylvestre Ledru a écrit :<br>
      </div>
      <b>getURL() and getURLcontent()</b>:<br>
      At the first glance, it is hard to understand the difference
      between getURL() and <br>
      getURLcontent(). Actually, it is very slight. Since it is only a
      matter of output and<br>
      that 90% of their respective jobs are the same, in my opinion,
      this does not <br>
      deserve 2 distinct functions: It would be nicer to add an option
      specifying the<br>
      output, or even more simply to have a second optionnal output
      argument:<br>
      <font face="Courier">[filename [, content]] = getURL(...)</font><br>
      It is always possible to specify a trash-file as filename.<br>
      or<br>
      <font face="Courier New">output = getURL(...,"returnContent")</font><br>
      At least, for the moment, a single help page merging the
      description of both <br>
      functions would be nice.<br>
    </blockquote>
    It implemented your proposal. <br>
    The profile of getURL is now:<br>
                [filename, [content]] = getURL(URL [, targetDir [,
    username [, password]]]]);<br>
    and getURLcontent has been removed.<br>
    Thanks for your proposal, it is indeed way better.<br>
    <br>
    It should be available in the next nightly builds.<br>
    <br>
    <blockquote cite="mid:514DA6E1.6070808@free.fr" type="cite"> <br>
      <u>Present embarassing limitations w.r.t. curl features</u>:<br>
      The most frustrating one is that these functions allow only
      queries in GET method.<br>
      The POST method is not available,  whereas curl allows it with no
      problem and<br>
      very great utility.<br>
      => So: It would be very useful to add a <font face="Courier
        New, Courier, monospace">curl_options</font> string optionnal
      parameter,<br>
      that would be passed to curl as is, allowing to post data with "-d
      param=value ...etc"<br>
      and any other curl usage.<br>
      By the way, specifying a file in which to dump the targetted
      content is possible <br>
      in this way. Proxy parameters can also be specified.<br>
      <br>
    </blockquote>
    It is not that easy to implement (all options won't be available,
    they are taking different types of arguments, etc) but <br>
    I will work on this later.<br>
    <blockquote cite="mid:514DA6E1.6070808@free.fr" type="cite">
      Presently, it is not natural to use atomsSetConfig() to specify a
      proxy to use for <br>
      getURL...().<br>
    </blockquote>
    I agree with you. We could:<br>
    * move the proxy configuration as something more global to Scilab<br>
    * manage it with preferences() and a dedicated function.<br>
    <blockquote cite="mid:514DA6E1.6070808@free.fr" type="cite"><br>
      <br>
      <b>splitURL()</b>:<br>
      works fine :-) IMO, its help page should be located in the "paths
      - filenames"<br>
      subsection, together with fileparts() and other paths-processing
      functions.<br>
    </blockquote>
    Done<br>
    <br>
    Thanks again for your suggestion,<br>
    Sylvestre<br>
  </body>
</html>