>
>> I went through and merged the two proposals here:
>>
>> http://wiki.opensocial.org/index.php?title=Messaging_API_Changes
>>
>> Comments?
>
>
> Hi Paul,
>
> Can we keep the original URIs that include inbox/outbox as we had
> before?
inbox semantics are available as @all
outbox is available as @outbox
This conforms to the existing opensocial norms that designate special
collection names with an @ prefix.
> --- begin ---
> Recipients can request messages by requesting them from their 'inbox'
> collection for received messages or 'outbox' collection for sent
> messages. If {msgid} is omitted, all messages are returned.
>
> GET /messages/{guid}/inbox/{msgid}
> GET /messages/{guid}/outbox/{msgid}
>
> Recipients can remove messages by sending a DELETE request to either
> the inbox or outbox. A message may also be updated with a PUT request
> (i.e., marking the messages as 'read'). In a DELETE or PUT request,
> {msgid} is required.
> --- end ---
>
> If you'd prefer not using "inbox" and "outbox," then I'd like to see
> some other comments at least.
I got rid of that syntax once I added support for generic message
collections. I'm willing to be flexible here, I just want to insure
that opensocial required collections are distinct from container
optional collections.
> The status strings that we had used before were "READ" and "UNREAD" --
> do you think those should be standardized? I can see a potential
> problem with something like "SPAM" since a message could be both read
> and spam at the same time. We could have I guess any number of status
> fields (e.g., one specifically for read/unread), but I don't want to
> propose making too big a change now.
Correct this is a messy area.
Long term goal would be to use atompub style categorization to use
defined terms tagged to each message.
http://atompub.org/rfc4287.html#element.category
For now I'm happy to stick with READ/UNREAD/DELETED and ignore the
spam aspect.
> Thanks,
> Bobby
>
> >
Paul Lindner
plin...@hi5.com
Im a general +1 on this.
Some notes:
- Message does not contain a msg collection id, is this intentional as it seems useful
- In the examples the message ids are URLs not URNs?
- Is anyone actually using body_id and title_id ? Maybe we can just drop these
- What is the body of the response to POST /messages/{guid}/@outbox when item was created? The entity itself?
On Mon, Nov 10, 2008 at 1:16 PM, Paul Lindner <plin...@hi5.com> wrote:
I went through and merged the two proposals here:
http://wiki.opensocial.org/index.php?title=Messaging_API_Changes
Comments?
On Nov 8, 6:55 am, snoopdave <snoopd...@gmail.com> wrote:
> +1 for getting thesechangesinto OpenSocial v0.9.
>
> - Dave
>
> On Nov 3, 3:32 pm, bobby <bbiss...@gmail.com> wrote:
>
>
>
> > > Does anyone have anything extra to add to this discussion? It seems
> > > like no one is against the idea but that the original proponent has
> > > dropped off the thread.
>
> > Hi,
>
> > Didn't mean to give the impression that I had dropped off the thread.
> > I thought your "1 +1 (submitter)" covered me. Am still in favor of the
> > proposal.
>
> > Cheers,
> > Bobby
- What is the body of the response to POST /messages/{guid}/@outbox when item was created? The entity itself?Right now it's just a simple 201 created response, I believe. Since an outbox can have multiple recipients there's no sense in returning what you posted. The IDs are going to be different for each user.
I certainly can get something going for error handling for v.NEXT.
I'd like to get some feedback for some potential small tweaks to the
Mesaging API. At hi5 we've put the draft protocol into production and
are working with one partner who is developing against it.
Here's the smallish set of changes:
* Add new messaging types -- FRIEND_REQUEST, MEDIA_COMMENT
* Add support for media comments at the message collection and message
level.
** For message collections and messages allow MEDIAITEM fields as a
singular ID that links with the Media/Albums proposal.
** Also recommend that url type 'photo' is a link to an originating
photo, and type 'thumbnail' a link to the thumbnail.
* Add descriptive text stating that:
-- While each container can support any number of message
collections each should support retrieving specific types of messages
from the @inbox and @outbox message collections. This will allow
application authors to support the differing message types in a
standard way. To get specific messages filtered by type use the
collection options as follows:
filterBy=type filterOp=equals filterValue={publicMessage|
privateMessage|notification|...}
* Question -- should we modify the JS API for newMessage(BODY,
OPT_PARAMS) to newMessage(PARAMS) ?