[0.8.1] Don't fetch all profile details by default

[Chris Chabot]

The discussion on this topic can be found at:

http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/4857f9ac3bdf803c?hl=en#

The current concern is that always returning all profile details when no fields are specified puts a to high strain on the bandwidth consumption and server resources.

The current proposal is to add a ?fields=@all or ?fields=* to the specification and return a default set of fields when no fields are specified (id, name, profile url and thumbnail url?)

Another question raised is how this spec change would affect the PortableContacts alignment effort, see the thread at:

http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/4fece6592a7bfa94?hl=en

I suggest that once we have feedback from John Panzer & Joseph Smarr about how this influences the PortableContacts alignment, we can quickly put this to a vote.

[Cassie]

+1 for the proposal
(and i like @all over * but whatever)

[Joseph Smarr]

I'm fine with this proposal, and it's consistent with the general philosophy for other query parameters in the aligned Portable Contacts proposal, namely: if the consumer doesn't request anything particular, it's up to the provider to return what they want, and if the consumer wants something specific, they should ask for it. So just as we propose that if no count is specified in the request, the provider can choose to only return say 10 contacts by default (instead of all of them), I think it's reasonable that if no fields are requested, a reasonable subset can be returned.

I would push for id and name to ALWAYS be returned, since they're required fields, but otherwise I think it's reasonable to leave this up to the provider. I'd prefer fields=@all to fields=*, but can we just do fields=all -- I don't think we'll ever have a contact field called "all" and I'm not sure confusing it with selector params is helpful here, just a thought...

Thanks, js

[Ropu]

+1

I agree with Joseph, but still i would have some "minimum mandatory" subset as a default, ie: "ID, Name, ThumbailURL"

and if the request ONLY includes one field (mandatory or not) ie, Gender, ONLY return that field

ropu

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

[Chris Chabot]

Hey Joseph, thanks for the feedback & i'm happy to hear this doesn't conflict with the PortableConflicts alignment proposal.

So with that cleared up, let's focus this thread then on voting for the actual proposal:

Add a fields={all, @all, *} to the specification, which will mean that the container should all the fields; And by default only returns a limited subset of the fields, which must always include id and name.

[Ropu]

An other question, when you say

Add a fields={all, @all, *} to the specification, which will mean that the container should all the fields;

you mean all the container supported fields, that could be a subset of all the OpenSocial fields with a minimum of Id and Name, but not necessary all of them.

ropu

Hmmm, this gives me a question, can we use this to determine the Container Supported Fields?

[Chris Chabot]

all the container supported fields, sorry for the typo :)

[Joseph Smarr]

Yeah, sounds good to me. The wording should hopefully be quite similar to proposal #2 in the PortableContacts alignment doc (http://docs.google.com/View?docid=dchtjj6f_3fw2b95d9), namely:

Clarify that if no 'fields' value is requested, it is up to the Provider which fields to return, though the returned fields MUST include id and name, since they are required fields. If a Consumer requests fields=all, the Provider SHOULD return all supported and available fields for the returned contacts.

BTW, Ropu: I don't think thumbnailUrl should always be returned--not all contacts have photos, particularly for more traditional address-book-like providers. I think id and name should be the only required fields. Also, I don't think if you ask for fields=gender that we omit id and name--how else do you know which contacts the gender is for? For simplicity and clarity, I think id and name should ALWAYS be returned--I don't think creates too much inefficiency...anyone else have an opinion here?

Thanks, js

[Louis Ryan]

+1 on id & name. The opensocial JS specifiies id,name,thumbnail&profileURL but it can explicitly ask for those.

+1 for @all for consistency on reserved identifiers.

[Ropu]

From
http://code.google.com/apis/opensocial/docs/0.8/reference/#opensocial.Person.Field

only ID, NAME, NICKNAME (?) and THUMBAIL_URL  are the fields withOUT the OPTIONAL tag

---
so fields={someFields,}
will return MandatoryFields (from above) + SomeFields

im ok with that.

ropu

[Michael Ryan (Software Developer)]

+1 on “*” for this… since “*” doesn’t need to be url encoded, where @ should be (in this case). 

 

* is a special character (no need to url encode) @ is a reserved character, not being used as part of the path statement in this case (after the path statement, part of the querystring).

 

--

Michael J. Ryan  --  Software Developer  --  Apollo Group

 

This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

[Michael Ryan (Software Developer)]

Agreed the default, and superset calls should contain all non-optional fields.

See prior post of fields=* vs. other terms.

 

--

Michael J. Ryan  --  Software Developer  --  Apollo Group

 

 

[Louis Ryan]

Michael

@ is already use all-over the RESTful api specification for reserved identifiers (@me, @self, @friends,...). I haven't heard that their use there is problematic, if you believe otherwise can you comment on the spec as a whole?

-Louis

[Joseph Smarr]

So...not that I care strongly about this per se, but wouldn't fields=all be safer (no @, no url-encoding issue, and no one is going to have a field called "all" so it's not a conflict)? :) But otherwise sounds like we've quickly converged here, which is great to see! js

[Paul Walker]

I think we should add profile url to this list obviously, but

 

+1

 

Default URI w/ no fields parameter values specified should not result in all fields. 

 

Seeing the consensus here, @MySpace I’ve added this as a defect to our current implementation and we will be responding w/ the four fields of id/urn, name, image uri, profile uri for now.

 

~Paul

pwa...@myspace.com

 

From: opensocial-an...@googlegroups.com [mailto:opensocial-an...@googlegroups.com] On Behalf Of Ropu

Sent: Tuesday, July 22, 2008 11:57 AM
To: opensocial-an...@googlegroups.com

[Michael Ryan (Software Developer)]

It’s designation is okay when used as part of a path…   http://server/path/to/@

 

It’s when it’s used as a value in a querystring…  http://server/path/to/?somevar=@somevalue

That it should be % encoded…  as it is a query value, not a resource path.

[Louis Ryan]

Good point, well made.

This brings up an interesting problem in the RESTful spec which allows for arbitrary structure of the URIs to identify resources via URI templates in XRDS. Does this choice of reserved identifiers prevent people from using query parameters for things like @self etc. on their site. This seems quite unfriendly and unnecessarily constraining the set of web-frameworks and platforms with which it will work. Do we need to reconsider our use of @ altogether?

[Michael Ryan (Software Developer)]

It should probably be okay, I would suggest testing at least apache, and iis against using an unencoded @ in a querystring param… it wouldn’t surprise me if they still worked, it’s merely that they shouldn’t be used that way, not that they can’t…  at least afaik (based on url encoding spec).

 

Also, using them in a restful manner as part of the resource path should be okay.

[Cassie]

hmm... I like @all to be consistent with all of the other @s we have.
It is currently working in the url for shindig as we use appId=@app (not in the spec... that's another thing we have to address in another thread)

If we can't use @all in the url params then I definitely think we should reconsider using @ altogether - consistency is important.


so +1 on having an "all", +1 on it being @all or on us changing all of the @s to something else
+1 on the default set of fields being explicitly stated in the spec as "id, name, thumbnailUrl" to agree with the js spec.

- Cassie

[chabotc]

This proposal got the required 5 +1 votes, and no votes against, so is
accepted for the 0.8.1 specification.

Also convergence was found on defining "id, name, thumbnailUrl" as
being the fields returned by default when no fields have been
specified so that it is consistent with the JS api.

The issues that still remain, is of using '@' as an identifier (since
it has to be encoded when used in query parameters), and related to
the discussions about that Cassie Doll has suggested making the URL
formats part of the specification, no voting has happened on this yet,
and i hope we can find convergence on this soon.

On Jul 22, 10:59 am, Chris Chabot <chab...@xs4all.nl> wrote:
> The discussion on this topic can be found at:http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...

>
> The current concern is that always returning all profile details when  
> no fields are specified puts a to high strain on the bandwidth  
> consumption and server resources.
>
> The current proposal is to add a ?fields=@all or ?fields=* to the  
> specification and return a default set of fields when no fields are  
> specified (id, name, profile url and thumbnail url?)
>
> Another question raised is how this spec change would affect the  

> PortableContacts alignment effort, see the thread at:http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr...