Hi Christian, I'm joining in to Derrell's hails, you're doing a really good job :). As I've promised to look at the RpcMockup issue, this post is mainly about it.
> http://qooxdoo.org/contrib/project#rpcconsole > http://qooxdoo.org/contrib/project/rpcconsole > > This debugging tool should be pretty stable by now and could very well be > 1.0 soon. I am still waiting because I am still interested in feedback on > the mockup data generation feature > (http://qooxdoo.org/contrib/project/rpcconsole#creating_mockup_data) through > the rpcconsole.MRpcMockup mixin. For one thing, I see you have taken a different approach than I had in mind with an additional transport. You chose to patch qx.io.remote.Rpc directly, which looks interesting but I would be curious about your rational. Your approach is more tightly integrated and hence offers a certain comfort ("monitor"ing a request exchange, then replaying it with the "on" mode). That's kind of cute, but relies on the qx.io.remote.Rpc implementation. I thought of a looser coupling using the Transport API, which will be probably much more stable than internals of the Rpc class. In my scenario the monitoring would be done by the rpcconsole itself, not the Rpc class, and the replaying would be achieved by switching to the Mockup transport class in the code, supplying the captured data. This requires code change, yes, but wouldn't you change your code, too, removing the use of the MRpcMockup mixin, or at least "on" and "monitor" modes, etc., before going into production?! Your approach is really charming for ad-hoc, interactive sessions, my requires more fiddling, saving trace data to a file, loading this file again, etc. But I'm really concerned about open and stable interfaces. What if you want to re-use captured data in regression tests, over and over again? What if, for large applications, you don't want to interactively capture the rpc traffic at all, but want to generate it from scratch?! These are the things I don't see possible with your approach. So my current summary would be: MRpcMockup: - comfortable - tight coupling - relies on Rpc internals (unreliable interface) - only for ad-hoc, interactive usage Mockup Transport class: - less comforable - loose coupling - relies on transport API and the Json data format for the rpc call trace (more stable interfaces) - good for automated tests, also with generated request data T. ------------------------------------------------------------------------------ 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
