On Fri, Dec 5, 2008 at 11:24 AM, Henning P. Schmiedehausen <
[EMAIL PROTECTED]> wrote:
> Louis Ryan <[EMAIL PROTECTED]> writes:
>
> >--001485f625a8726eb5045d506bfe
> >Content-Type: text/plain; charset=ISO-8859-1
> >Content-Transfer-Encoding: 7bit
>
> >There is definitely some scope for cleanup in the Shindig code with regard
> >to how we handle filters and sorts. The REST/RPC spec are clearer on how
> >this should be done and the cruftiness in the Shindig code is mostly a
> >remnant of how poorly filtering was defined in the original JS API.
> >ALL - I think is redundant and can probably be eliminated. If the rest
> call
> >is
> >/people/{guid}/@friends
> >the only reason to support an @all pre-canned filter is if the container
> >applied a different filter by default which would be pretty odd. The
> client
> >side JS is free to do so of course.
>
> >HAS_APP - Im not sure there are any good examples of how this should be
> >mapped in the spec but I would think something like
> >/people/{guid}/@[EMAIL PROTECTED]&filterOp=equals&[EMAIL PROTECTED]
> >would be the most general formulation. Containers are free to make this
> the
> >default filter behavior if none is specified
>
> >IS_FRIENDS_WITH - There was recent discussion of this on the spec list and
> >it was broadly agreed that this would become
>
> >/people/{guid}/[EMAIL PROTECTED]&filterOp=equals&filterValue={guid}
> >where @friends in this context is a virtual filed on the initial set of
> >resolved people prior to filtering
>
> >TOP_FRIENDS - This is either a sort or a group but again modeling it as a
> >filter seems odd.
>
> >Given that we are now branched we have to live with the somewhat awkward
> >mapping we have today. As for what containers need to support I think
>
> No. We don't have to live with it because we branched. We have to live
> with it because the 0.8.1 spec has these types in its javascript
> API. Which, no matter how much discussion about the REST/RPC API is
> going on, is still the thing that 99% of all opensocial users care
> about. :-)
>
> >containers are'nt required to implement anything other than the ALL_FILTER
> >with paging and silently ignore the other ones. The spec isn't
> particularly
> >clear on this point.
>
> Thanks for the information, but you kind of missed my question. :-)
> There is a defined js API which gadgets use and it does not contain a
> FilterOperation. Only a filter type
> (opensocial.DataRequest.FilterType). So the question is (and I should
> have been clearer here): If no filter operation is given, should I
> assume "FilterOperation.equals"? I need to spec out this to our
> backend guys.
The point I was making is that you shouldnt maintain a 1:1 mapping of the JS
to what you dispatch internall. The fact that the existing JS gives you
filterBy={ALL|HAS_APP|IS_FRIENDS_WITH|...} and no filterValue or filterOp
doesnt mean you
should map it to that internally. I would suggest you do the up-conversions
I listed above in your dispatch, or submit a patch that does this for the
Shindig js.
>
>
> Ciao
> Henning
>
> --
> Henning P. Schmiedehausen - Palo Alto, California, U.S.A.
> [EMAIL PROTECTED] "We're Germans and we use Unix.
> [EMAIL PROTECTED] That's a combination of two demographic groups
> known to have no sense of humour whatsoever."
> -- Hanno Mueller, de.comp.os.unix.programming
>
