<div dir="ltr"><div><div><div>Hello Alex,<br>Thank you for all the infos. So:<br></div>- we would join improving REST 2.0 (rtx-rest),<br></div>- we would develope an angularjs (or backbone.js) client.<br><br></div><div>
I hope our work would be useful for all the RT community. <br><br><br><br></div><div>Hello Community,<br></div><div>If anyone has angularJS or backbone.js competency and could join us (any way), just let us know please. <br>

</div><div><br></div><div>Thanks,<br><br>Ákos<br></div><div class="gmail_extra"><br><br><br><div class="gmail_quote">On Wed, Mar 12, 2014 at 8:33 PM, Alex Vandiver <span dir="ltr"><<a href="mailto:alexmv@bestpractical.com" target="_blank">alexmv@bestpractical.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, 2014-03-06 at 17:21 +0100, <a href="mailto:akos.torok@docca.hu">akos.torok@docca.hu</a> wrote:<br>


> This is some kind of request for comment. Please, feel free to give us<br>
> advice, support, ideas. If you have similar effort, if you know any<br>
> solution that makes this problems causeless, let us know please!<br>
<br>
</div>Best Practical is always interested in contributions from the community<br>
which improve the product.  As it happens, our focus for RT 4.4 is<br>
planned to include a concentration on the UI, as well as a rewrite of<br>
the REST API.<br>
<br>
For RT 4.2, we held to our previous restrictions that the entirety of<br>
the UI needed to be accessible to users without JS enabled.  With<br>
JS-based UIs sufficiently prevalent now, it is our intent with RT 4.4<br>
that JS will be a required part of the UI.<br>
<br>
That being said, we do not intend to write the entirety of the UI in JS,<br>
as a thin wrapper around back-end APIs.  Such a rewrite would be<br>
extremely time-intensive, and unlikely to be able to duplicate all of<br>
the features of the current server-side templating solution.<br>
<br>
However, we're quite interested in improving the REST API.  The 1.0 REST<br>
API was written well before the advent of JSON, and indeed before the<br>
concept of "REST APIs" had begun to be commonplace -- as such, it has a<br>
number of very odd design decisions that hinder extensibility.  Because<br>
of this, we are uninterested in expanding on it, but are more focused on<br>
providing a new implementation which is based on modern assumptions of<br>
how REST APIs should function.<br>
<br>
We currently have an initial sketch of a REST 2.0 already partially<br>
completed, with the aim to release it as an extension for RT 4.2, in<br>
core in RT 4.4, and remove REST 1.0 thereafter.  It is now published at<br>
<a href="https://github.com/bestpractical/rtx-rest" target="_blank">https://github.com/bestpractical/rtx-rest</a> -- it also requires the RT<br>
branch <a href="https://github.com/bestpractical/rt/tree/4.2/support-rest-v2" target="_blank">https://github.com/bestpractical/rt/tree/4.2/support-rest-v2</a><br>
<br>
Bear in mind that this is highly experimental; we do _not_ suggest its<br>
use apart from developers working on it.  It is in no way<br>
production-ready.  As we are aware it is lacking in features, pull<br>
requests or patches welcome; simple bug reports are not helpful at this<br>
juncture.<br>
<span class="HOEnZb"><font color="#888888"><br>
 - Alex<br>
<br>
<br>
<br>
--<br>
RT Training London, March 19-20 and Dallas May 20-21<br>
<a href="http://bestpractical.com/training" target="_blank">http://bestpractical.com/training</a><br>
</font></span></blockquote></div><br></div></div>