Please, I need some help with this, I just need to know if I'm on the right track
Thanks, Gabriel On Wed, Jul 14, 2010 at 8:53 PM, Gabriel Guardincerri <[email protected]>wrote: > 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 >> > >
