With files sent by the server via the file storage features, and not as part of workunits, when the project asks the client to upload a file, the upload URL is *added* to the list of URLs. So the file_info ends having the upload_when_present flag, and two URLs:
http://example.com/project/download/398/file1.zip http://example.com/project_cgi/file_upload_handler (I mentioned this in my giant "BOINC file storage features" message to boinc_projects) With this change: http://boinc.berkeley.edu/trac/changeset/18427 How does the client know which is the upload URL? Will it try to POST to the file1.zip URL? [begin useless if-I-could-do-BOINC-from-scratch rant] The problem is the current <url> element is used to give URLs, but they are handled in a completely different way depending on whether it's a download or an upload. That means the tag is ambiguous. For downloads, it's the URL of a file, and the client GETs it. For uploads, it's the URL of a program that accepts an upload, and the client POSTs custom protocol data to it. Cleaner ways would have been: - Use different tags for download and upload URLs, to remove the ambiguity. You can be sure it will never POST to a download URL, or try to GET from the file_upload_handler URL. - Don't use a custom protocol; the same URL could be used to either GET or PUT data. Then, when I ask the client to download a file, I send it a data/file1.zip URL, and when I want it back, I tell it to upload, and it could PUT to that same URL. [/useless rant] _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
