On 09/06/14 12:13, Ian Dickinson wrote:
On Fri, Jun 6, 2014 at 9:22 AM, Andy Seaborne <[email protected]> wrote:
The upload is a standard file upload - multipart with a parameter for the
graph name (or "default" or empty) and a file content part.
The upload approach is problematic at scale:
The graph name can come after the file content so you don't know the
destination until you see the whole request. That is, the request needs to
be buffered. And the jquery-fileuploader does seem to send the name after
the content.
One way to approach this would be to use the long-running tasks
infrastructure that you've set up. In the first step, we post a new
graph name to the /upload endpoint, which returns the URL for
uploading the graph content to in step 2. Would that work?
What a cunning plan.
A kind of action (with graph name) that creates a destination URL for
the file upload that is wired to its dataset destination at the start is
doable. The URL can include some large unique number to make it
reasonably secure.
If it could just send the file content, not a browser file upload, the
URL could be POST to the graph store protocol URL but the file uplaod to
a magic one-off URL ispretty similar it shouldn't be hard to do at some
time.
As things stand at the moment, it won't work because long running tasks
are just monitored for completion, with no web-facing-ness.
For now, shall we stick to the file upload as-is, which is workable for
small and medium sized files so that this issue is not a blocker?
Andy
It would be better to only use the SPARQL Graph Store Protocol for data
upload but that's was beyond my capabilities in finite time of dealing with
files etc from within the browser.
I don't think you can monkey with the files that are picked by the
file input control. In general, JavaScript isn't permitted to access
the contents of files from the browser's host OS.
Ian
