shindig-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Chabot (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SHINDIG-1136) Content upload for php shindig
Date Mon, 03 Aug 2009 10:55:14 GMT

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


Mime
View raw message