Rather than doing this we should do something akin to what we've done for the JSON-RPC introspection support in osapi. i.e
1. osapi makes a gadgets.rpc to container asking for the supported methods. 2. Container returns that list in the format used for JSON-RPC's system.listMethod 3. osapi binds the returned services in the same manner it supports it for JSON-RPC, erasing the protocol backed ones if a name collision occurs 4. osapi will now dispatch those api calls of gadgets.rpc On Tue, May 19, 2009 at 12:36 PM, Sachin Shenoy (JIRA) <[email protected]>wrote: > osapi (oslite) should support user mediated requests. > ----------------------------------------------------- > > Key: SHINDIG-1065 > URL: https://issues.apache.org/jira/browse/SHINDIG-1065 > Project: Shindig > Issue Type: New Feature > Reporter: Sachin Shenoy > > > According to osapi spec any request can be user mediated. (there is no more > osapi.ui.*). Shindig to support mechanism for user mediated requests. > > Changes: > - Containers can via configuration let shindig JS know which requests it > want to be user mediated. > - Predefined hooks are used to pass the request to the container and get > the response back. > - A new type of request, osapi.newUiRequest is defined to handle user > mediated case. Even though this is in global space, it need not be visible > to the developer directly. Developer uses the osapi as today. > - batch.js is modified to allow handling of user mediated requests. > - So that developer can know which request may get user mediated, every > request exposes a boolean field userMediated (this is not part of standard > but could be good to have something like this for future version). This > would allow developers to write code like below, > > var r = osapi.activites.create(); > if (r.userMediated) { > // skip creating activity, as I don't want to bug the user. > } else { > r.execute(); > } > > > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
