[
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.
