Hi Louis, Could you please look into this change?
Thanks, Sachin On Fri, May 22, 2009 at 11:14 PM, Sachin Shenoy <[email protected]> wrote: > 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. >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> > >
