Proposal: change to osapi:recipient format

[bobby]

Hello all,

I originally brought this up in a proposal for messaging changes, but
it may be more appropriate brought up as a separate issue. In my
messaging post, I suggested a change to allow a recipient to include
more information than domain and id, for instance: example.org:
78gh37261ddfdf

In our container, a user can send messages to either a group or a
person, so it would be nice to allow another field so that recipients
could refer to something other than people (as currently written in
http://docs.google.com/View?docid=dcc2jvzt_37hdzwkmf8).

For instance:
person:example.org:78gh37261ddfdf
group:example.org:78gh37261ddfdf

The initial field ('person' or 'group' but there could be others)
could be optional. Because colons are not allowed in the container's
id for the person or group, or the domain, there would be no ambiguity
if a person's id was elsewhere represented as the form "a:b:c" or
"x:y" -- in either case the last instance of ":" separates domain from
container-specific ID.

Thanks,
Bobby

[Scott Seely]

We have 1 +1 on this item (the author).

Do we have any other votes/questions?

On Oct 16, 8:51 am, bobby <bbiss...@gmail.com> wrote:
> Hello all,
>
> I originally brought this up in a proposal for messaging changes, but
> it may be more appropriate brought up as a separate issue. In my
> messaging post, I suggested a change to allow a recipient to include
> more information than domain and id, for instance: example.org:
> 78gh37261ddfdf
>
> In our container, a user can send messages to either a group or a
> person, so it would be nice to allow another field so that recipients

> could refer to something other than people (as currently written inhttp://docs.google.com/View?docid=dcc2jvzt_37hdzwkmf8).

[Jamey Wood]

I agree with the goal of providing containers the flexibility to allow
for recipients other than individual persons. But I'm not sure how that
is best accomplished.

Would it be possible to just make colons legal in the container-specific
identifier portion of GUIDs? Then, containers could elect to use IDs like:

example.org:person:78gh37261ddfdf
example.org:group:58bc72316eae1f

...which would still lead to legal URNs, like:

urn:guid:example.org:person:78gh37261ddfdf
urn:guid:example.org:group:58bc72316eae1f

Another option might be to leave GUIDs alone and instead add metadata
into the messaging markup. For example, perhaps:

<entry xmlns="http://www.w3.org/2005/Atom"
xmlns:osapi="http://opensocial.org/2008/opensocialapi"
xmlns:myapi="http://my.container.com/2008/osextensionsapi">

<osapi:recipient><osapi:person>example.org:AD38B3886625AAF</osapi:person></osapi:recipient>

<osapi:recipient><myapi:group>example.org:997638BAA6F25AD</myapi:group></osapi:recipient>
...
</entry>

--Jamey

[Louis Ryan]

Currently the REST spec (2.3) when referring to user relative groups is using

example.org:34KJDCSKJN2HHF0DW20394/friends

as the id and urn:guid:example.org:34KJDCSKJN2HHF0DW20394/friends for the urn. Note that this already extends the id conventions so its reasonable to assume we can do the same for types and other structures

I personally have no problem with a convention like

<domain>:[<type>:]<alphanum id>[/path]

where <type> is optional but has reserved names for the already specified opensocial types. Containers are then free to use it or not. 

The use of paths to represent relative structures probably deserves some discussion as its likely that

example.org:34KJDCSKJN2HHF0DW20394/friends

to represent a user owned group will have namespace collision issues with other entity types owned by a user

This is a fairly big ticket decision so Im not comfortable voting until this thread gets some broad feedback.

[Scott Seely]

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.

I will call the thread dead in Wednesday AM if we don't see some more
discussion.

On Oct 29, 8:06 am, "Louis Ryan" <lr...@google.com> wrote:
> Currently the REST spec (2.3) when referring to user relative groups is
> using
>
> example.org:34KJDCSKJN2HHF0DW20394/friends
>
> as the id and urn:guid:example.org:34KJDCSKJN2HHF0DW20394/friends for
> the urn. Note that this already extends the id conventions so its
> reasonable to assume we can do the same for types and other structures
>
> I personally have no problem with a convention like
>
> <domain>:[<type>:]<alphanum id>[/path]
>
> where <type> is optional but has reserved names for the already
> specified opensocial types. Containers are then free to use it or not.
>
> The use of paths to represent relative structures probably deserves
> some discussion as its likely that
>
> example.org:34KJDCSKJN2HHF0DW20394/friends
>
> to represent a user owned group will have namespace collision issues
> with other entity types owned by a user
>
> This is a fairly big ticket decision so Im not comfortable voting until this
> thread gets some broad feedback.
>

[bobby]

> 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,

I didn't know I had dropped off the thread. :)

I agree with Louis that it would be nice to get more feedback, but
short of completely overhauling how identity is handled in OpenSocial,
it seems that the only thing to decide from this thread are whether
<type> goes before or after <domain>. I'm fine with having it after
domain, as is used in most of the examples above:
example.com:group:abc123

I haven't seen any response to Jamey's idea of adding metadata to give
the original ID more context, but if that is preferable then the
change to the messaging proposal would be simple to do. Of course, if
messaging gets approved as-is then I prefer the smallest change.

So to sum up, it looks like this is the final proposal: containers
must accept IDs such as example.org:abc123, but may optionally accept
example.org:<type>:abc123. The 'type' field in our container is either
'person' or 'group,' but I think making a list of reserved words now
might be premature.

Cheers,
Bobby

[Jamey Wood]

I'm not clear on how this is supposed to proceed from here. I also
agree with the sentiment that more feedback would be good. But so far,
it doesn't seem to be forthcoming.

So are we supposed to just take the absence of such feedback as a sign
that people are at least not strongly opposed to this, and vote on the
proposal that Bobby describes in his last paragraph above? If so, I'm +1.

--Jamey

[Ropu]

i like the idea bobby presents.

i assume that if <type> is NOT set, default should be 'person'

that is backwards compatible.

and i prefer the

example.org:<type>:abc123

format with the type after the Domain and before de ID

have this said, im +1 on this update to the messaging API

--
.-. --- .--. ..-
R  o  p  u

[Scott Seely]

Update from F2F:
No objections to adding object type to the message format. There was
some discussion as to how pervasive this is (or could be) in the
RESTful API. Louis Ryan of Google (lr...@google.com) will be following
up on the messaging thread with details.

[bobby]

On Nov 13, 10:10 pm, Ropu <rovagn...@gmail.com> wrote:
> [...]

> i assume that if <type> is NOT set, default should be 'person'
>
> that is backwards compatible.

Yep, that was my thinking, just to be clear.

Cheers,
Bobby

[Dave]

+1 on providing a way to send messages to groups in addition to people.

- Dave

[Scott Seely]

+1

On Nov 18, 11:08 am, Dave <snoopd...@gmail.com> wrote:

[Scott Seely]

Updated http://sites.google.com/site/opensocialdraft/Home/restful-protocol-specification#TOC-10.-Messaging-Optional-,
adding text to show how to support a group or a person within a
message.

(votes I saw were from bobby, ropu, dave, jamey, me).

Louis-- you mentioned that this may be more broadly applicable to
other parts of the spec. Do you see any issues with the edits to
section 10 that would preclude us from a broader solution in .NEXT?

[Bess Ho]

Wow more digestable... keep up the good parts
+1

--
Bess Ho

[Louis Ryan]

I think this is fine though it explicitly does not address the issue of user-relative groups such as "my friends" it only allows for identifying groups that are independent entities. Im fine +1 with  this limitation I just want to make sure people are aware of the issue

If we do want to allow for relative addressing of groups I dont think creating arbitrarily complex id structures is the way to go. I could be persuaded that something like "example.org:12345/@friends" is OK but we are getting close to the syntax of REST requests and we may just be better off allowing for composition by passing either REST URLs, RPCs or potentially OSQL references in the group. Something like

<osapi:recipient>http://www.example.org/person/12345/@friends?filterBy=@friends&filterOp=contains&filterValue=98765</osapi:recipient>

(borrowing form Pual's Is friends with proposal)

entry xmlns="http://www.w3.org/2005/Atom"

         xmlns:osapi="http://opensocial.org/2008/opensocialapi">

On Thu, Nov 20, 2008 at 2:00 PM, Scott Seely <sse...@myspace.com> wrote:

[Eiji Kitamura]

Hi,


I just had time to look at this proposal for the first time.
I have concern about group specification issue as Louis pointed out.
This proposal seems to be assuming that group IDs are unique container-wide, but our container have group ids as tiny integer number and it is relative to userIDs.

I agree with the idea of adding type. It could be used when for example, community identifier will be required in the future.
But for specifying group, what is not good about the spec we used to have?

I suggest alternate spec:

To specify single person:
example.org:78gh37261ddfdf
example.org:person:78gh37261ddfdf

To specify relatively friends of a person
example.org:person:78gh37261ddfdf/friends

To specify a group of a person
example.org:person:78gh37261ddfdf/58bc72316eae1f

To specify a container wide group
example.org:group:58bc72316eae1f


Eiji,

2008/11/22 Louis Ryan <lr...@google.com>:

[bobby]

On Nov 25, 12:45 am, "Eiji Kitamura" <agek...@gmail.com> wrote:
> I just had time to look at this proposal for the first time.
> I have concern about group specification issue as Louis pointed out.
> This proposal seems to be assuming that group IDs are unique container-wide,
> but our container have group ids as tiny integer number and it is relative
> to userIDs.

That is correct. This proposal is only meant to augment the current
case, which is that messages are sent to a single recipient. Except
that this proposal allows the recipient to be some entity other than a
person, for instance a group, but other entities could be possible.

I think that having recipients relative to some other entity should be
a separate proposal.

Cheers,
Bobby

[Louis Ryan]

I agree with Bobby on this and more specifically I do not want to introduce a compound id structure like the one Eiji has proposed piggybacked on this proposal, it is far too big of a change for that. Im still +1 on the current proposal as it stands

[Adam Winer]

I hadn't taken a close look at this specification until very recently
either; my apologies.

We already have the concept of "recipients relative to some other
entity"; in fact, it's inherent in the requestSendMessage() JS API,
where groupId can be specified relative to userId. I frankly can't
imagine how to implement requestSendMessage() in terms of an array of
recipient IDs. If a container can't implement requestSendMessage() as
it has and continues to exist using this proposal, then this proposal
should be dead in the water.

On the other hand, building up any sort of compound ID structure - as
proposed here - raises large questions with regards to the rest of the
specification. We should not have multiple ID concepts in the
specification, but what would passing one of these IDs to any of our
other endpoints mean?

So, while I agree with Bobby and Louis on Eiji's email, I'm currently
-1 on this proposal overall: no support for the existing concept of
groupIds is a big problem.

One ugly solution; redefine:

<osapi:recipient>example.org:group:AD38B3886625AAF</osapi:recipient>
to
<osapi:recipient>
<osapi:entityId>example.org:group:AD38B3886625AAF</osapi:entityId>
<osapi:groupId>@friends</osapi:groupId>
</osapi:recipient>

Restful URLs would support example.org:group:AD38B3886625AAF/@friends.
JSON RPC would be {entityId : "example.org:group:AD38B3886625AAF",
groupId: "@friends"}

-- Adam

On Tue, Nov 25, 2008 at 7:16 AM, bobby <bbis...@gmail.com> wrote:
>

[Bess Ho]

I don't know enough to vote this thread.

 

But it is important to be able to send message as notification. Facebook has significantly improved their story feed and notification points.

 

OpenSocial only got this thing down - one-line story feed - for viral distribution. No notification. Guess we won't have notification for X'mas.

--
Bess Ho

[Arne Roomann-Kurrik]

Bess,

   Messaging has been in the API since 0.7, when requestShareApp and requestSendMessage were both introduced.  Several containers currently have production implementations of public, private, and email messaging.  What's missing?

~Arne

--
OpenSocial IRC - irc://irc.freenode.net/opensocial

[Bess Ho]

It seemed like Yahoo implied this is not quite there for v0.8.

 

http://developer.yahoo.com/yap/guide/os-supp-features.html

Messaging

YAP does not support requestSendMessage and requestShareApp.

http://developer.yahoo.net/forum/index.php?showtopic=318

--
Bess Ho

[Adam Winer]

Yahoo didn't implement it.  Other containers do;  it's not a spec issue.

-- Adam

[Bess Ho]

Thanks. It is not clear on their site.

--
Bess Ho