In many ways the binding mechanism is an implementation detail. The information could just as easily go in container config. The main point is that the osapi code treats gadgets-rpc as just a transport for JSON-RPC style calls and the interfaces, packaging and format of the methods aligns closely with that for the dat-backed APIs. One advantage of following this design methodology is that it would easily allow a container to implement a fully mediated API. The concerns with the late binding that you list are valid and should be weighed against the advantages of a decoupled deployment process between the container and the gadget server.
On Tue, May 19, 2009 at 11:52 PM, Sachin Shenoy <[email protected]> wrote: > This would change the way we get the list of mediated methods but I guess > other stuff remains same? > Currently we are getting this list via configuration, but you suggest it is > better to get it by introspection with the container. With client side > introspection I see these issues, > > 1. Race condition. I think this can be solvable, by delaying the actual > call > of gadgets.util.runOnLoadHandlers. > 2. We force the containers to implement the introspection method, a > container failing to do so would cause bad things (we would wait > indefinitely for the callback). > 3. Any delay caused by the introspection(?) > > Sachin > > On Wed, May 20, 2009 at 5:38 AM, Louis Ryan <[email protected]> wrote: > > > 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. > > > > > > > > >
