I have uploaded a new patch which does the suggested introspection. Sachin On Thu, May 21, 2009 at 9:41 PM, Louis Ryan <[email protected]> wrote:
> All of these are valid approaches. We already introspect the > server-endpoint > for the JSON-RPC methods which gives a nice level of decoupling between > gadget server and API server. Having the same in the client is certainly > useful for gadget renderers that must interoperate with many containers. > > On Wed, May 20, 2009 at 10:41 AM, Sachin Shenoy <[email protected]> > wrote: > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > >
