Hi Burak, interesting points. I am in favor of streamlining the API to put different rpc transports on equal footing in terms of "namespace equality", although in my opinion, this should be an issue for post-1.0 releases. There is just so much code out there which does the json-rpc thing that would have to be refactored.
But I would be interested why you think that authentication etc. should be part of the transport? I like the idea of having a transport that is as transparent and simple as possible, an leave all the rest to the application and the backend. It seems to me that security and authentication requirements are just too diverse - no one single implementation can satisfy individual use cases. The simpler the transport, the simpler you can debug it without having to use external tools. Best, Christian Burak Arslan-2 wrote: > > > hello, > > you might remember my bringing up this issue some time ago. here it is > again. > > i think that the qx.io namespace must be redesigned, and the qx.io2 > namespace should be unified with qx.io (or should be renamed to > something else because it sounds too much like an ugly hack.) before > freezing the api. > > here are some issues, from my point of view: > > 1) qooxdoo must be able to support additional backend-communication > protocols. if it ever does, the most elegant way to do this is to have > classes like qx.io.rpc.Json, qx.io.rpc.Xml (xmlrpc) qx.io.rpc.Soap, etc. > > You may have noticed my reluctance to use jsonrpc. it's cute and compact > and all, but it lacks some important features like security, > routability, authentication, etc. so i don't think it is up to par with > today's enterprise requirements. So pushing JsonRpc as the one-size > solution for backend queries renders qooxdoo less flexible than it is > ought to. > > Without taking the anti-rest propaganda seriously, you can read the > following article with better explains reasons for my support of soap as > a backend-communications protocol: > http://wisdomofganesh.blogspot.com/2007/12/paying-restafarians-back-in-their-own.html > > i'd also like to note that the soap protocol has great server-side > support -- you don't need to roll your own. > > so, in short, i'm pretty sure that leaving room for other communication > protocols will certainly add to the value of qooxdoo. > > 2) all those hypothetic classes should inherit from a common qx.io.IRpc > a common rpc protocol interface. this will let us switch between > different protocols with a minimum amount of effort. > > 3) I think that the qx.ui.table.Table is a great idea, well executed. > Two points here: > > a) The "qx.ui.table.model" and "qx.ui.table.columnmodel" name spaces > don't > communicate their purposes precisely enough. i'd prefer to rename > them to > qx.ui.table.datasource and qx.ui.table.dataschema respectively. > maybe > better names could be suggested. > > b) The functionality of remote models could be applied to anything that > scrolls. Comboboxes, Listboxes, and the like could benefit from such > an abstraction. This also would make implementing an interface that > "brings suggestions while the user is typing" a breeze. > i guess this sums my thoughts up. i could file those separately as three > (four?) bug reports if you want me to. > > awaiting your feedback > > best regards, > burak > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > -- View this message in context: http://n2.nabble.com/rpc-in-qooxdoo-tp4058077p4058132.html Sent from the qooxdoo mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
