File Uploads

58 views
Skip to first unread message

Cameron Bytheway

unread,
Oct 1, 2012, 12:40:31 PM10/1/12
to collect...@googlegroups.com
Is there support in Collection+JSON for file uploads? I'd like to use it for a image service I'm working on where users can upload photos and tag regions with data.

mca

unread,
Oct 1, 2012, 12:44:19 PM10/1/12
to collect...@googlegroups.com
CJ has no special support for uploads built into the media type design.

I usually use multipart/form-data[1] media type as this is the best-supported on all client and server platforms and there lots of libraries for this already.

[1] http://tools.ietf.org/html/rfc2388

mca

Cameron Bytheway

unread,
Oct 1, 2012, 12:55:10 PM10/1/12
to collect...@googlegroups.com
The multipart/form-data would be used for sending the payload back to the server, right? Would we need to have an extension of CJ like the following?

{
  "collection": {
    "template": [
      {"name": "title", "prompt": "Title"},
      {"name": "image", "prompt": "Image", "file":true}
    ]
  }
}

When the client sees the field has a file attribute, it knows it needs to send a file instead of text.

Thoughts?

mca

unread,
Oct 1, 2012, 1:02:13 PM10/1/12
to collect...@googlegroups.com
Cameron:

i think the simplest way to do would be to support an extension on the template itself:

{
  "collection": {
    "template":
      type : "multipart/form-data",
      data :[
         {"name": "title", "prompt": "Title"},
         {"name": "image", "prompt": "Image", "file":true}
       ]
    }
}

I think you still need the file:true extension in order to tell the client app which fields will need to be handled as base64. it might be ok to use a "base64":true extension in order to break out from the file-based example, but that's proly going too far right now<g>.

I think this has been proposed via the templates[1] extension but could be added w/o requiring support for template collection.


[1] https://github.com/mamund/collection-json/blob/master/extensions/templates.md

mca


Cameron Bytheway

unread,
Oct 1, 2012, 1:19:33 PM10/1/12
to collect...@googlegroups.com
Mike:

Should I go ahead and write up an extension to support the template type setting? I'll probably also have to write one for the file template too.

PS Thanks for your quick replies

mca

unread,
Oct 1, 2012, 1:56:33 PM10/1/12
to collect...@googlegroups.com
yes, go ahead and write up a mod.

beset way is to clone the repo and build up a pull request w/ the new mode in the extensions folder.

then post that here in the list where folks can provide any comments/feedback.

Cheers.


mca


Cameron Bytheway

unread,
Oct 1, 2012, 4:48:07 PM10/1/12
to collect...@googlegroups.com
Just made a pull request. Let me know of any questions or concerns.

mca

unread,
Oct 1, 2012, 4:55:30 PM10/1/12
to collect...@googlegroups.com
thanks for turning this around so quickly.

some things to consider.
- in cases where the the client does not support this media type, how should the client behave. for example, there are existing implementations, they will proly ignore the type and file properties and (i suspect) sent the actual "file.ext" value.

- i'd reference the RFC on mulipart/form-data to help folks sort out what they need to do when implementing this extension for their clients.

- since you're adding the type value, this opens the door to lots of other "types" (app/x-form-urlencoded, text/plain, etc.). i think you might need to include some guidance/explanation along those lines including what client do when no value is present.

- essentially, the RFC sez to use base64 encoding to upload the file. do you want to write the extension to do this only on files? maybe other large/binary payloads (inline images, etc.) or other cases where base64 erncoding a form value makes sense?



mca


Cameron Bytheway

unread,
Oct 1, 2012, 5:17:48 PM10/1/12
to collect...@googlegroups.com

- in cases where the the client does not support this media type, how should the client behave. for example, there are existing implementations, they will proly ignore the type and file properties and (i suspect) sent the actual "file.ext" value. 

The backwards compatibility issue is always tough... The first thing that comes to my mind is send a url pointing to the file on an external entity. That still requires the client to do a bit of work but may not be too bad. Not sure about this one...
 
- i'd reference the RFC on mulipart/form-data to help folks sort out what they need to do when implementing this extension for their clients.

My intention was to be able to set the type to anything.  Essentially what this ext is adding is support for the CU H-Factor, which may be opening a bigger bag of worms that I originally anticipated, which is fine; we'll just have to work it out :)

- since you're adding the type value, this opens the door to lots of other "types" (app/x-form-urlencoded, text/plain, etc.). i think you might need to include some guidance/explanation along those lines including what client do when no value is present.

Yes we definitely need some explanation of what to do by default.  I was thinking application/json but I'm not entirely sure.  What is the default type the original spec defines?  That's probably what we should go with if one is defined.

- essentially, the RFC sez to use base64 encoding to upload the file. do you want to write the extension to do this only on files? maybe other large/binary payloads (inline images, etc.) or other cases where base64 erncoding a form value makes sense?

It would be helpful not to limit it to files for sure. The problem i see with the use of base64 as the key is we're now tied to only having multipart/form-data. Maybe attachment is a better term?

mca

unread,
Oct 1, 2012, 5:23:59 PM10/1/12
to collect...@googlegroups.com
"The backwards compatibility issue is always tough... The first thing that comes to my mind is send a url pointing to the file on an external entity. That still requires the client to do a bit of work but may not be too bad. Not sure about this one..."
- yeah, this happens today in HTML when folks don't change the enctype value; the content of the field (the filename itself) is sent. i think that's fine.

"My intention was to be able to set the type to anything.  Essentially what this ext is adding is support for the CU H-Factor, which may be opening a bigger bag of worms that I originally anticipated, which is fine; we'll just have to work it out :)"
- yep - i'm OK w/ this. i think some folks at Nokia Research were doing the same thing (using app/x-form-urlencoded, etc.). for now, update the text to ack that in the extension, give a few slight examples, and i think we're fine.


"Yes we definitely need some explanation of what to do by default.  I was thinking application/json but I'm not entirely sure.  What is the default type the original spec defines?  That's probably what we should go with if one is defined."
- the orig sez to send the JSON collection so we should be sure to call that out as the default when nothing is present.


"t would be helpful not to limit it to files for sure. The problem i see with the use of base64 as the key is we're now tied to only having multipart/form-data. Maybe attachment is a better term?"
- actually, this is all pure speculation on my part. not sure we actually need this on anything other than files right now and we can always address that later.


mca


Cameron Bytheway

unread,
Oct 4, 2012, 2:21:48 AM10/4/12
to collect...@googlegroups.com
I am still working on this FYI. I just got really busy the past couple of days.
Reply all
Reply to author
Forward
0 new messages