OpenSocial and Gadgets Specification Discussion Google Group

Re: Proposal for 1.0 -

2009-11-26T03:32:45Z

It seems to me that it's actually extra work to deny re-assignment to
a variable. The loop assignment to a variable in repeaters is
absolutely required, IMO. Disallowing it outside repeaters seems
somewhat arbitrary. Content blocks are processed sequentially. Loops
execute sequentially. (Inline) templates are rendered sequentially.

Re: Clarify Separation of Gadgets (Data Sections) (issue154120)

2009-11-25T21:03:22Z

I'll try to get a revised version of this after the holidays.

Jon

Re: [osgs] Re: Description for the user id field

2009-11-25T19:55:59Z

right, so I think it's okay if this happens, but we should recommend that it
doesn't happen.

Re: Description for the user id field

2009-11-25T19:13:47Z

This was "option 2"

Re: [osgs] Re: Description for the user id field

2009-11-25T19:02:55Z

yes - one object has one id. A developer should be able to check if viewer
== owner by comparing their ids.

I thought the scenario we were talking about was more related to if it's
okay to have John's user id = 1234, and also have some activity out there
with activity id = 1234.

-Lane

Re: [osgs] Re: Clarify Separation of Gadgets (Data Sections) (issue154120)

2009-11-25T17:50:02Z

Yes...we need to do that. BodyType is currently shown as type String, but
it's really a type of it's own with properties like eyeColor, height,
weight, etc (which are all type string).

It could go in either. I just figure since it's an object with known
properties it would fit in the Core-Data spec, but I don't feel to strongly.

Re: Description for the user id field

2009-11-25T17:45:11Z

What about the "variant" and id refers to one object, and one object
has one id.

It's really only workable if we make it a MUST.

I would like to make it a MUST. Think about this simple use case. A
gadget developer wants to know if the viewer and owner are the same,
how do they do it? compare IDs? Only works if the mapping is one-to-

Re: [osgs] Re: Question on Section 9 of Gadgets Spec...

2009-11-25T17:40:43Z

Yes...I'm hoping to send out a patch/preview of the merged Core-Gadget and
Gadget-XML today.

X-Gadget includes anything that can go in a gadget: JS, Data Pipelining,
Templating. Since "features" (in the Require feature="foo" sense) go in
gadgets, I think they should be covered in X-Gadget. If they define any new

Re: Clarify Separation of Gadgets (Data Sections) (issue154120)

2009-11-25T17:36:46Z

As to BodyType - I see now, there are a lot of enums which I had
handled as "one of: xxx, yyy..." in the description field. We could
pull these out and make special types for them.

I'm still a bit lost on responseItem, shouldn't that be part of the
REST/RPC specifications?

OK for others.

Re: [osgs] Re: Description for the user id field

2009-11-25T17:28:17Z

How about we go with #1 (unique ID per object type) and RECOMMEND #2 (unique
ID across all objects).

-Lane

Re: OpenSocial Extensions section in OpenSocial-Specification.xml

2009-11-25T17:18:44Z

Of course!
[link]
This should be the source file for the XML and the code we used to
demonstrate it. The code is an eclipse patch on BETA3, but should work
on trunk. This should work, but if not, I'll find another external
site and plop it there.

Re: Question on Section 9 of Gadgets Spec...

2009-11-25T17:17:20Z

The content for Section 9 is good, but there should be 2 "section 9"s.
One for "Core" and one for "Social".

As a documentation standard we have X-Data, X-Gadget, X-API-Server (is
the future plan to move Gadget-XML to Core-Gadget?). Since these refer
to the JavaScript APIs (and only JS APIs?) each X-Data should properly

Re: [osgs] Re: Clarify Separation of Gadgets (Data Sections) (issue154120)

2009-11-25T17:15:01Z

These fields are really more related to profile fields on a person. For
example, BodyType refers to fat/skinny, eye color, not HTML docs.
(
[link]
)

Email only has "address" and "type" field, which is redundant to the

Re: OpenSocial Gadget Specification & Feature Versioning patch [v1.0] (issue152136)

2009-11-25T17:08:51Z

Tim,
Thanks for clarifying. I think what's not clear here is who's doing
what when. That is, we are trying to cover multiple scenarios, e.g.
gadget registration, user adding this to a page, deployment of
gadgets, et... This makes it very difficult for us to write language
that covers all of these situations. I don't think for 1.0 we want to

Re: [osgs] Re: OpenSocial Extensions section in OpenSocial-Specification.xml

2009-11-25T17:03:38Z

I've uploaded the latest version I have to
[link]

It's looking good so far. I think we should add a section that briefly
outlines the process for developing and accepting extensions (but mostly
just links to the spec process doc), then list the currently accepted