Thanks Paul. On Tue, Jul 20, 2010 at 11:07 AM, Paul Lindner <[email protected]>wrote:
> 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 >
