Hi John, About Jira, I've found this https://issues.apache.org/jira/browse/SHINDIG-738, but I don't have the permissions to assign it to me, my username is gguardin.
Question about the spec: >From what I understand from the spec, when you upload a content, it should be upload to some Data Object that supports it. The only one that I've found that supports it is MediaItem, and MediaItems can be associated to Activities and Albums. So when someone is making a request to upload a file is also requesting to create a MediaItem, or something else, associated to the uploaded file. An then associate that MediaItem to an Album or Activity. The specs also keeps the option of uploading files and associate them to other things different than MediaItem "A *common* place to apply content upload will be against an existing Album or MediaItem endpoint." It also seems to allow uploading a file and to no create a new entity "In most scenarios an uploaded content is associated with creation of an entity", but I can't see how that will work, since there doesn't seems to be a Data Type to represent a file that could be retrieved. So, if I understand correctly, uploading a file is more like a special type of parameter that some other data types may have. I mean, if we want to send a string with the title to a new Activity, we just send as a json string param, but if we want to send a file as a param, we need all this new way that's in the spec, i.e. http://opensocial-resources.googlecode.com/svn/spec/1.0/Core-API-Server.xml#Content-Upload, and that param will be "assigned" to that entity. Therefore it isn't a new service that can be used directly. But is something that will be called if someone that is creating a, for example, MediaItem is also passing as a "param" a file. If so, then the servlet that is listening for REST or RPC calls, should check if that call contains a file, if so, it should store the file somewhere and pass and ID or something to the actual method that is being called, and that method should be able to know what to do. Another thing is how to get that file that was upload. I think that the spec relies on a URL to get it, i.e. it gives you the URL of the file and it can be used to get it, e.g. www.mycompany.com/images/323432.jpg. To sum up: - When a user wants to upload a file it should be also being creating some entity that will be related to it. - An uploaded file is more like a param than a service. - To get a file there's an URL. About the implementation: We would need, as you said in the previous email, a base interface for persistence, since we need to write the uploaded data somewhere. But I'm not sure if we need a Handler. Instead of that, we may a need something like current BeanConverter to convert the binary content into a file (and storing it using the former persistence interface), and then passing the ID (or something like that) as a param to the entity that is being created, in most cases a MediaItem. I mean to treat the binary data as a param, a param similar to a json string for the title of the MediaItem, but instead of being in json format it would be in binary format. WDYT? Gabriel On Thu, Jul 8, 2010 at 4:33 PM, John Hjelmstad <[email protected]> wrote: > Looking forward to it. As always, send a note to the list if you run into > trouble, or would like help w/ the code review process. > > Speaking of this, it's often nice to manage a project like this via the > JIRA > issue tracker: > http://issues.apache.org/jira/browse/SHINDIG > > Your mileage may vary. > > --j > > On Thu, Jul 8, 2010 at 12:05 PM, Gabriel Guardincerri <[email protected] > >wrote: > > > Awesome, great info! > > > > On Wed, Jul 7, 2010 at 8:12 PM, John Hjelmstad <[email protected]> wrote: > > > > > Hi Gabriel: > > > > > > Great to hear! As luck would have it, Charles Severance recently wrote > up > > > some documentation on how to add a new API to the social-api server > here: > > > > > > > > > http://www.dr-chuck.com/csev-blog/2010/07/playing-with-shindigopensocial-adding-a-new-feature-and-a-service/ > > > > > > I suspect this will provide a nice bootstrap for your needs, in concert > > w/ > > > the spec itself. Parameter name "body" should give you access to the > > > request > > > body, from [Social]RequestItem.getParameter(...). > > > > > > As for the implementation itself, perhaps this is obvious but I'd > suggest > > > something like: > > > 1. Introduce base interface for persistence ie. > > > ContentUpload[Persistence|Service], with operations read(...) and > > > write(...), in: > > > > > > > > > http://svn.apache.org/repos/asf/shindig/trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/spi/ > > > 2. Introduce default implementation (eg. filesystem-based) for #1. > > > 3. Write ContentUploadHandler in: > > > > > > > > > http://svn.apache.org/repos/asf/shindig/trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/service/ > > > , > > > with persistence @Inject'ed > > > - Implements the real semantics of the API per spec. > > > 4. Don't enable use of the default handler (#2) by default; you don't > > want > > > to enable new functionality that uses nontrival hardware resources w/o > > > service providers being aware. Instead document the default handler > (for > > > testing) and indicate how a custom such handler may be supported. > > > > > > Cheers, > > > John > > > > > > On Wed, Jul 7, 2010 at 2:33 PM, Gabriel Guardincerri < > [email protected] > > > >wrote: > > > > > > > Hi John, > > > > > > > > I'm going to start adding this feature to shindig, I will be working > > with > > > > the Java version. Any start points/advices about this? > > > > > > > > Thanks > > > > > > > > Gabriel > > > > > > > > On Thu, Jul 1, 2010 at 10:56 AM, Gabriel Guardincerri < > > > [email protected] > > > > >wrote: > > > > > > > > > Hi John, > > > > > > > > > > I'm interested in having that feature, so I could probably > contribute > > > to > > > > > Shindig instead of making a workaround. Do you have an idea of how > > hard > > > > > would it be to add this to Shindig? > > > > > > > > > > Thanks, > > > > > > > > > > Gabriel > > > > > > > > > > > > > > > On Wed, Jun 30, 2010 at 1:31 PM, John Hjelmstad <[email protected]> > > > > wrote: > > > > > > > > > >> Hi Gabriel: > > > > >> > > > > >> afaik you're not missing anything. This part of the opensocial 1.0 > > > > >> spec isn't implemented in Shindig yet. We'd be happy to accept > > > > >> contributions. Do you use php, java, or both? > > > > >> > > > > >> John > > > > >> > > > > >> On Wednesday, June 30, 2010, Gabriel Guardincerri < > > [email protected] > > > > > > > > >> wrote: > > > > >> > Hi, > > > > >> > > > > > >> > I'm not sure if this is the right list to post this questions, > but > > > it > > > > >> seems > > > > >> > to be the more active. Please let me know if I need to post it > in > > > > >> another > > > > >> > list. > > > > >> > > > > > >> > I'm using Shindig and I would like to be able to store files, > > things > > > > >> like > > > > >> > images, videos, word documents, etc. I've tried to do that but > it > > > > seems > > > > >> to > > > > >> > the REST services don't support headers with content types like: > > > > >> > > > > > >> > Content-Type: image/gif > > > > >> > Content-type: multipart/form-data > > > > >> > > > > > >> > On the other side it seems that Opensocial Spec > > > > >> > > > > > >> > > > > > > > > > > http://opensocial-resources.googlecode.com/svn/spec/1.0/Core-API-Server.xml#Content-Uploadhas > > > > >> > a spec for doing that. > > > > >> > > > > > >> > So, am I missing something? If not, is this going to be > supported > > or > > > > >> there a > > > > >> > way to extend Shindig to support this? > > > > >> > > > > > >> > Thanks in advance, > > > > >> > > > > > >> > Gabriel > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > >
