PSPP-BUG: [bug #18692] Allow URLs in system/portable file specifications

[Ben Pfaff]

Update of bug #18692 (project pspp):

                  Status:                    None => Ready for Test/Review  

    _______________________________________________________

Follow-up Comment #1:

I am inclined to fix this bug by adding a suggestion to the documentation
that one can read data directly from a URL by using a pipe file name that uses
a helper program, e.g. "|curl
http://janda.org/c10/data%20sets/vote92/vote92.por";.  A patch that implements
this, and fixes a few bugs I encountered while testing it, is attached.

I considered two alternatives:

* Link against curl or libwww (from w3c), as jmd suggested.  Long term, this
might be a good solution.  The problem is that we'd have to add an additional
layer of wrappers over stdio to make this reasonable for the client code.  I
can certainly do that, but I'm slightly concerned about making it efficient in
the common case (though I don't have any evidence that it would be
inefficient), readable, and simple all at the same time.  Also, there is an
impedance mismatch between curl/libwww and PSPP: curl wants to provide data
through callbacks, which isn't convenient, so we'd have to do buffering.  

* Fork a "curl" or "wget" process and communicate with it over a pipe.  The
only problem here is that mingw32 doesn't have fork, and I'd like to make this
a general-purpose solution.  We could use popen, which is implemented by
mingw32, but then error reporting would suffer: the subprocess would only be
able to report errors via its exit status (popen doesn't provide a way to
intercept stderr).

(file #13525)
    _______________________________________________________

Additional Item Attachment:

File name: url-files2.patch               Size:5 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?18692>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/