On Mon, Jun 2, 2008 at 1:48 PM, David Primmer <[EMAIL PROTECTED]>
wrote:
> Would it be too much to bring up the issue of versioning Shindig so
> that we don't have to do these types of things in the source tree?
> Implementing what I see as two versions of the services in the same
> trunk works for our case, so I suppose I'd agree to this workaround
> (we need other changes to the service interfaces as well) but I'm sure
> there are others situations where developers are doing things like
> this. Maybe someone would like to propose a method to version the
> codebase so we can don't have to straddle .7 and .8 compliance in the
> same codebase? It will have to happen eventually.
I talked about this a bit at I/O, and proposed branching / freezing once we
had 0.8 compliance; nobody really seemed to express an opinion one way or
another, other than expressing a desire for getting stable, compatible
releases eventually.
Right now shindig isn't really 0.7 or 0.8, it's somewhere in between the
two. If you really limited apps to only stuff available in 0.7, you'd have a
platform that's of limited use (which is why we had the 0.8 changes in the
first place).
The obvious problem here is that almost everyone has to implement some of
the interfaces, but most will only be altered by a small minority of users.
Changing something that accesses app data or activities is certainly more
dangerous than changing a parser.
So, we probably should set some realistic goals for a release. I feel that
we'd be constraining ourselves to little benefit if we do this before 0.8 is
fully implemented, but I'm certainly open to arguments on the contrary.
Individual artifacts can be frozen at different times so long as they remain
compatible with one another at all times.
>
> davep
>
> On Mon, Jun 2, 2008 at 1:36 PM, Cassie <[EMAIL PROTECTED]> wrote:
> > Ah, I understand the bug you filed much better now Dave. So, in the js
> apis
> > you aren't currently allowed to say which app the data is coming from.
> This
> > is why the service apis have the app id specified through the token. So,
> we
> > can definitely change this, but we will probably want to branch the
> service
> > interfaces - we may finally be at a point where this is necessary.
> >
> > So, I think we should create three new interfaces for the rest services -
> > and then we will have the Basic*Service impls just implement both the
> json
> > interfaces and the rest interfaces. Later on, we can remove the
> deprecated
> > json stuff when restful is sufficient as a replacement.
> >
> > What do ya think?
> >
> > - Cassie
> >
> >
> > On Mon, Jun 2, 2008 at 8:20 AM, Louis Ryan <[EMAIL PROTECTED]> wrote:
> > This restriction makes it difficult to provide services for a viewer for
> > which the container does not want to expose an ID such as a request for
> > permissions. we may need to consider an extended syntax to refer to the
> > viewer and owner in an auth token as part of the projection (@viewer
> @owner
> > ?)
> > On an unrelated note it seems order of the appdata url parts is
> backwards.
> > Based on the premise that removing elements of the path continues to make
> > the URL useful I dont see much use for
> >
> > /appdata/{guid} --Fetching data across a set of applications for a
> single
> > user
> >
> > whereas
> >
> > /appdata/{appid} -- Fetching data across a set of users for a single
> > application.
> >
> > seems much more likely. The former case will almost certainly be
> completely
> > disallowed for ACL reasons but the latter can be used by an application
> > backend to read data from its installed user base.
> >
> > On Fri, May 30, 2008 at 3:30 PM, David Primmer <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Sticking to "token is only auth context" helps as a general rule.
> >> That means all variables in the url win as far as selecting the data
> >> to be operated on and id's from tokens are used only in ACL checks.
> >>
> >> There are exceptions to this and I hope in the future we can augment
> >> the current url patterns with full auth-aware projections that are a
> >> combination of acl and query for those that want to be explicit.
> >> Google calendar does something like this with the full and basic
> >> projections. Your token will give you the projection you have rights
> >> to if you don't specify it, but at least it is possible to ask for
> >> more data than you should see and get denied.
> >>
> >> This means all the data interfaces need to be able to take these
> >> variables as parameters and not expect info to be slipped through in
> >> the token. The DataService.java and BasicDataService are examples of
> >> components in need of upgrades.
> >>
> >> davep
> >>
> >> On Fri, May 30, 2008 at 3:02 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
> >> > It would seem to me that the url param should always win, but you
> still
> >> need
> >> > data from the token to make it all make sense in the first place
> (@self,
> >> for
> >> > instance).
> >> >
> >> > app id should probably always be derived from the url (assuming it's
> an
> >> app
> >> > data-centric call, of course). App ids are public.
> >> >
> >> > The real question here is -- can any arbitrary app request data from
> >> another
> >> > app? Is it ok for appid "foo" to get data for appid "bar"? I believe
> the
> >> > answer here is "yes", in which case the appid passed in the security
> >> > credentials is simply used to identify the source of the request,
> *not*
> >> the
> >> > target of the operation (this is generally true for all fields in the
> >> > tokens).
> >> >
> >> > On Fri, May 30, 2008 at 2:28 PM, David Primmer <
> [EMAIL PROTECTED]>
> >> > wrote:
> >> >
> >> >> I have a general question about token handling precidence in the Rest
> >> >> api server. It appears that some of the information encoded into the
> >> >> rest urls is also in the token. When getting a url like this for app
> >> >> data /appdata/{uid}/@self/{aid} you'd normally think that putting
> >> >> somehting into {uid} and {aid}, userid and appid would affect the
> >> >> query on the backend data, but if the contents of the token override
> >> >> anything in the url, you're basically turning the appdata service
> into
> >> >> an rpc endpoint called 'getAppDataForUser' and then passing in a
> >> >> token. So what's the point of the rest service here?
> >> >>
> >> >> Is the rule that the url semantics are there for when oauth is used?
> >> >> Seems like these values are also intended to be encoded in a custom
> >> >> oauth header. So what's the deal here? Should the url drive the query
> >> >> composition and be verified by the token and throw an error if the
> two
> >> >> don't match? Should the server ignore the elements in the url
> favoring
> >> >> the token?
> >> >>
> >> >> thanks.
> >> >>
> >> >> davep
> >> >>
> >> >
> >>
> >
>
