Hello Burak,
its interesting that you come up with that topic. Not even two hours ago I
talked to Fabian about your first two topics. As you sure know, we can not
just move stuff without deprecating them. So one thing is for sure, there
will be a io2 namespace in the release. But we plan to deprecate it and get
it all to the io namespace.
I also agree with you that we should have another implementation for all the
transport things in the framework. But I don't know either if or what time
we will have the resources to implement new code. Sure not before a 1.0
release. That needs some more time to think about and to implement.
For your bug question, there is already bugs open for the io2 namespace.
http://bugzilla.qooxdoo.org/show_bug.cgi?id=1163
Regards,
Martin


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-tp4058077p4059112.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

Reply via email to