[jira] Commented: (SHINDIG-1136) Content upload for php shindig

["Chris Chabot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SHINDIG-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738276#action_12738276 ] 

Chris Chabot commented on SHINDIG-1136:
---------------------------------------

The code it's self looks alright, but there's a something that isn't quite clear to me on how it's intended to work:

- In the input converter you try to json_decode the post body, however a post with a media item attached should have a Content-Type: image/*, audio/* or video/* content type, so I would think the json input converter would never be called in the first place when it's a raw binary data media item upload.

- Instead I would expect something like 'If this is a POST to the media item url, and the content-type is image/*, audio/* or video/*, call the container's SPI implementation and ask it to validate and create a new media item, returning the ID to it'. (see the 'two step upload' in http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/REST-API.html#rfc.section.3.7)

- If the image/audio/video format is not accepted by the container (either because it's corrupted data, or because someone tried to upload something that isn't a valid image at all (think using it as a distribution method: uploading zip files but pretending they are images in the hope the container will host them for you), there should be a clear way for it to reject the upload. The Partuza reference implementation should def check on this as an example, if it only does images and rejects video & audio that's fine by me, just as long as implementers have the choice on what they want to support

- On a POST with a media item url, the container would probably want to have a local copy as well (performance, security by validating before accepting (see above), being able to generate thumbnails etc); Wouldn't it be easier for the implementers if we just fetched the data for them, and pretended it was a regular content upload? (with the content-type being the content-type that we recieved when fetching the remote content)

I'll commit what we have so far, but I hope you can either explain how the above already works, or address those issues

> Content upload for php shindig
> ------------------------------
>
>                 Key: SHINDIG-1136
>                 URL: https://issues.apache.org/jira/browse/SHINDIG-1136
>             Project: Shindig
>          Issue Type: New Feature
>          Components: PHP
>         Environment: php 5.2.4
>            Reporter: Jinhui Du
>
> The URL for code review is http://codereview.appspot.com/98103/show

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.