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.
> 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).
> 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.
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:
Scott Seely wrote: > 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).
>> 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.
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.
On Tue, Oct 28, 2008 at 9:19 AM, Jamey Wood <Jamey.W...@sun.com> wrote:
> 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:
> Scott Seely wrote: > > 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).
> >> 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.
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.
> On Tue, Oct 28, 2008 at 9:19 AM, Jamey Wood <Jamey.W...@sun.com> wrote:
> > 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:
> > Scott Seely wrote:
> > > 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).
> > >> 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.
> 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.
bobby 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,
> 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.
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.
On Fri, Nov 7, 2008 at 5:26 AM, Jamey Wood <Jamey.W...@sun.com> wrote:
> bobby 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,
> > 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.
> 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.
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.
On Nov 13, 7:10 pm, Ropu <rovagn...@gmail.com> wrote:
> 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
> On Fri, Nov 7, 2008 at 5:26 AM, Jamey Wood <Jamey.W...@sun.com> wrote:
> > bobby 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,
> > > 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.
> > 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.
On Tue, Nov 18, 2008 at 10:51 AM, bobby <bbiss...@gmail.com> wrote: > 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.
+1 on providing a way to send messages to groups in addition to people.
> On Tue, Nov 18, 2008 at 10:51 AM, bobby <bbiss...@gmail.com> wrote:
> > 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.
> +1 on providing a way to send messages to groups in addition to people.
(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?
On Nov 19, 1:00 pm, Scott Seely <sse...@myspace.com> wrote:
> On Nov 18, 11:08 am, Dave <snoopd...@gmail.com> wrote:
> > On Tue, Nov 18, 2008 at 10:51 AM, bobby <bbiss...@gmail.com> wrote:
> > > 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.
> > +1 on providing a way to send messages to groups in addition to people.
> (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?
> On Nov 19, 1:00 pm, Scott Seely <sse...@myspace.com> wrote:
> > +1
> > On Nov 18, 11:08 am, Dave <snoopd...@gmail.com> wrote:
> > > On Tue, Nov 18, 2008 at 10:51 AM, bobby <bbiss...@gmail.com> wrote:
> > > > 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.
> > > +1 on providing a way to send messages to groups in addition to people.
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
> (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?
> On Nov 19, 1:00 pm, Scott Seely <sse...@myspace.com> wrote: > > +1
> > On Nov 18, 11:08 am, Dave <snoopd...@gmail.com> wrote:
> > > On Tue, Nov 18, 2008 at 10:51 AM, bobby <bbiss...@gmail.com> wrote: > > > > 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.
> > > +1 on providing a way to send messages to groups in addition to people.
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*
> 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
>> 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?
>> On Nov 19, 1:00 pm, Scott Seely <sse...@myspace.com> wrote:
>> > +1
>> > On Nov 18, 11:08 am, Dave <snoopd...@gmail.com> wrote:
>> > > On Tue, Nov 18, 2008 at 10:51 AM, bobby <bbiss...@gmail.com> wrote:
>> > > > 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.
>> > > +1 on providing a way to send messages to groups in addition to
>> > > people.
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.
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
On Tue, Nov 25, 2008 at 7:16 AM, bobby <bbiss...@gmail.com> wrote:
> 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.
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"}
On Tue, Nov 25, 2008 at 7:16 AM, bobby <bbiss...@gmail.com> wrote:
> 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.
On Tue, Nov 25, 2008 at 10:05 AM, Adam Winer <awi...@gmail.com> wrote:
> 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.
> 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 <bbiss...@gmail.com> wrote:
> > 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.
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?
On Tue, Nov 25, 2008 at 3:58 PM, Bess Ho <bess...@gmail.com> wrote:
> 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.
> On Tue, Nov 25, 2008 at 10:05 AM, Adam Winer <awi...@gmail.com> wrote:
>> 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.
>> 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 <bbiss...@gmail.com> wrote:
>> > 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.
> 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
> On Tue, Nov 25, 2008 at 3:58 PM, Bess Ho <bess...@gmail.com> wrote:
>> 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.
>> On Tue, Nov 25, 2008 at 10:05 AM, Adam Winer <awi...@gmail.com> wrote:
>>> 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.
>>> 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 <bbiss...@gmail.com> wrote:
>>> > 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.
>> 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
>> On Tue, Nov 25, 2008 at 3:58 PM, Bess Ho <bess...@gmail.com> wrote:
>>> 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.
>>> On Tue, Nov 25, 2008 at 10:05 AM, Adam Winer <awi...@gmail.com> wrote:
>>>> 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.
>>>> 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 <bbiss...@gmail.com> wrote:
>>>> > 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.
On Tue, Nov 25, 2008 at 4:36 PM, Adam Winer <awi...@gmail.com> wrote:
> Yahoo didn't implement it. Other containers do; it's not a spec issue.
> -- Adam
> On Tue, Nov 25, 2008 at 4:18 PM, Bess Ho <bess...@gmail.com> wrote:
>> It seemed like Yahoo implied this is not quite there for v0.8.
>>> 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
>>> On Tue, Nov 25, 2008 at 3:58 PM, Bess Ho <bess...@gmail.com> wrote:
>>>> 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.
>>>> On Tue, Nov 25, 2008 at 10:05 AM, Adam Winer <awi...@gmail.com>wrote:
>>>>> 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.
>>>>> 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 <bbiss...@gmail.com> wrote:
>>>>> > 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.
