<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">Hello Sylvestre,<br>
<br>
Le 24/01/2013 18:14, Sylvestre Ledru a écrit :<br>
</div>
<blockquote cite="mid:51016C0E.3060306@scilab-enterprises.com"
type="cite">
<pre wrap="">Hello,
The attachment describes the SEP #88, targeting Scilab 5.5.0.
The goal of this SEP is to propose the introduction of three new functions:
* getURLcontent - Return the content of an URL (HTTP, HTTPS, FTP...)
Profiles:
filename = getURL(URL [, targetDir [, username [, password]]]]);
filename = getURL(URL [, targetFile [, username [, password]]]]);
* getURL - Download an URL (HTTP, HTTPS, FTP...)
Profile:
output = getURLcontent(URL [, username, [, password]]);
* splitURL - Split a URL (HTTP, HTTPS, FTP...)
Profile:
[proto, server, path, query, username, port, fragment] = splitURL(URL);
Don't hesitate to comment it,
Sylvestre</pre>
</blockquote>
Sorry for the delay. The good thing is that now there is more
information in the help<br>
of the beta-implementation available in the 5.5 branch; and it is
possible to test them.<br>
<br>
I developped some utilities under Scilab with curl ~3 years ago,
and i had a look <br>
on how to use these new functions instead of my owns. Here are some
comments<br>
and suggestions about their present implementation.<br>
<br>
<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>
<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>
Presently, it is not natural to use atomsSetConfig() to specify a
proxy to use for <br>
getURL...().<br>
<br>
In few words, it could be a good basic target to have a simple
interface with curl,<br>
such as a curlScilab() function.<br>
The only problem i had when using curl through unix_#() functions
was some<br>
encoding issues in the output content. getURL...() greatly fix this
point. <br>
Otherwise, curl is so great that is is a big improvement to include
it the Scilab <br>
package for all plateforms (not only Windows). <br>
<br>
Other advanced features could be useful, such as allowing to follow<br>
<META HTTP-EQUIV="Refresh" CONTENT="n ; url=new_target" ><br>
within a limited nesting depth ; and other ones. <br>
More elaborated functions could be posted to ATOMS or FileExchange.<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>
<br>
Best regards<br>
Samuel<br>
<br>
</body>
</html>