Hi Dan i've just sent the proposal the the spec list
http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/12bd4b524169618a regards ropu On Sun, Sep 28, 2008 at 10:35 PM, Dan Peterson <[EMAIL PROTECTED]> wrote: > Ropu, can you drop the spec proposal to the spec list? > -Dan > > On Fri, Sep 26, 2008 at 12:57 PM, Ropu <[EMAIL PROTECTED]> wrote: > > > +1 to add the field in the Messaging REST API spec... > > > > is a small change to avoid multiple implementations and move from the > > standard > > > > ropu > > > > On Fri, Sep 26, 2008 at 3:21 PM, Rodrigo Gallardo <[EMAIL PROTECTED] > > >wrote: > > > > > On Fri, Sep 26, 2008 at 01:28:10PM -0400, Bobby Bissett wrote: > > > > Hi Rodrigo and all, > > > > > > > > I've attached my simple jsonmessage.js file (mostly it just adds a > > > > toJsonObject method) and related diffs. > > > > ... > > > > org.apache.shindig.social.opensocial.model.Message > > > > - This is a minor change, but it's an API change so it's a bigger > > > > deal. To match the rest/rpc proposal, I added a list of recipients to > > > > the class so that they can be pulled out in the message handler. > > > > > > I also lean towards this solution. Given how nothing inside shindig is > > > actualy using that part of the API, it should not be a very painful > > > change. > > > > > > > I see > > > > that's a todo in your handler; the recipients could be another param > > > > in the post body, but I don't think that works well in the rest case > > > > without clashing with the messaging URI template. > > > > > > The whole rest code assumes a single argument payload in the HTTP body, > > > so doing this clashes completely with it all. > > > > > > > One other issue is that, when returning a message to the client, > there > > > > needs to be some way to include the sender information. Another field > > > > could be added to Message, or this could be handled in an impl- > > > > specific way. > > > > > > I'd add another field. Even thought getting messages is not part of > this > > > spec we should try to get a common way to do it. maybe we should even > > > propose to add it to the API. > > > > > > > > > > > -- > > .-. --- .--. ..- > > R o p u > > > -- .-. --- .--. ..- R o p u
