I have another questions, is about the file's metada, I think that from the spec, there's no need to store any metada of the file. That should be handled by some other entity, in most cases MediaItem. The only problem that I see with that is how does Shindig know that should delete the file when the MediaItem entity is deleted. Any ideas?
Thanks, Gabriel On Wed, Jul 14, 2010 at 3:49 PM, Gabriel Guardincerri <[email protected]>wrote: > Hi, > > I'm implementing Content > Upload<http://opensocial-resources.googlecode.com/svn/spec/1.0/Core-API-Server.xml#Content-Upload>spec > and I have a few question to be sure that I'm understanding it > correctly: > > I wrote an extend exaplantion in a post with title "Uploading and storing > files data", but it can be summarized in that Uploaded Content is a param > for some other action. I mean, if we want to create an Activity that > contains an image, the we call the create activity service with the usual > params of the activity and also with a file as a param. Uploading a file > param is not easy, so this spec is about how to handle that. > > If that interpretation is right, then uploading content is an extension on > what type of params can be used to create/update any entity. Therefore we > need a general way to handle files that could be used by potentially any > service. > > So, I'm right now trying to implement the RPC part of the spec, since it > can be used from the browser and all the multipart-form handling code is > already there in Shindig. > > Just to start with something I've modified AppDataHandler to handle binary > files (I know that the spec says that App Data only handles Strings values, > but I need something like for myself, I'll port this to meet the spec). So > now the AppDataHandler.create(...) method is able to handle files if they > are in the SocialRequestItem. It saves the file using a new > service ContentUploadService. Then replace the key that is mapped to that > file, e.g: > > If the there is a values map with: > > "data" : { > "image":"@field:image1" > } > > Then it searches for a FormMimePart with name "image1", saves the content > to a new file, gets this file's ID and changes that value with it: > > "data" : { > "image":"<fileID>" > } > > Then continues as before. > > I'm not sure if that's the best place, I mean that Handles handle the file > storage and then resolving the reference to the file. The good side of this > is that each handler would be able to decide what to do with file params. > The bad side is that it could be resolved when the raw content of the > request is being converted, so it would be transparent to handlers. Any > suggestion on this? > > Another thing is that I'm not sure about how to get that file, I mean to > see it in the browser, AFAIU the file ID could be actually an URL that can > be used to get the file. Is this right? > > So WDYT? I'm on the right way? > > BTW, I'm attaching a patch with the changes. > > Thanks, > > Gabriel >
