You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Gabriel Guardincerri <gg...@gmail.com> on 2010/07/14 20:49:16 UTC
Questions about how to implement Upload Content spec
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
Re: Questions about how to implement Upload Content spec
Posted by Gabriel Guardincerri <gg...@gmail.com>.
Thanks Paul.
On Tue, Jul 20, 2010 at 11:07 AM, Paul Lindner <pl...@linkedin.com>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 <gguardin@gmail.com
> >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 <
> gguardin@gmail.com
> > >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 <
> > gguardin@gmail.com>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 -- plindner@linkedin.com -- linkedin.com/in/plindner
>
Re: Questions about how to implement Upload Content spec
Posted by Paul Lindner <pl...@linkedin.com>.
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 <gg...@gmail.com>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 <gguardin@gmail.com
> >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 <
> gguardin@gmail.com>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 -- plindner@linkedin.com -- linkedin.com/in/plindner
Re: Questions about how to implement Upload Content spec
Posted by Gabriel Guardincerri <gg...@gmail.com>.
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 <gg...@gmail.com>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 <gg...@gmail.com>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
>>
>
>
Re: Questions about how to implement Upload Content spec
Posted by Gabriel Guardincerri <gg...@gmail.com>.
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 <gg...@gmail.com>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
>