I would love to have a decoupled deployment. One thing that can be done is to do server side introspection. Let the gadget renderer introspect the mediated methods much like the normal methods via "mediatedMethods" call? Sachin
PS. Going a step further (may be a bit too further), an endpoint could support a "getConfig" method. Gadget server could query that to get the json config that would be merged with the static configuration before inserting it into the iframe. On Wed, May 20, 2009 at 10:24 PM, Louis Ryan <[email protected]> wrote: > 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. > > > > > > > > > > > > > >
