Adding Scott Seely, who proposed the original spec and may know of how MySpace implemented content upload.
Regards, Paul On Fri, Jul 16, 2010 at 1:41 PM, Gabriel Guardincerri <[email protected]>wrote: > 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 > >> > > > > > -- Paul Lindner -- [email protected] -- linkedin.com/in/plindner
