Hey, On Wed, May 21, 2014 at 1:41 AM, Dan Haywood <d...@haywood-associates.co.uk>wrote:
> > From what I read here, it seems that my goals with Kirra are more related > > to RO than to Isis per se (as Isis design assumes client and provider are > > in the same process and there is no latency), although I could still see > it > > working with an Isis implementation with some loss of functionality. > > At the moment, that's true, though in RO is starting to move in that > direction. > > In RO v1.1 [3] (which .NET implements, not yet Isis) we have the concept of > property prompt and action parameter prompt. These enable conditional > choices to be computed, eg Category/Subcategory. > > I can see usefulness in that for sure, but the design probably looks different than in a framework meant for local (in-process) clients (instead of callbacks, you do a GET on some URL). In Kirra, for instance, there are methods that Dan,can be invoked to determine the "domain" of a parameter or of a relationship, i.e. candidate objects for a relationship or a parameter (code API source [4] and live REST API [5] - look for slots named domainUri). Also, now that I think about it, even in RO 1.0 we made the validate > functionality available as a callback; hit the put/post resource, with an > optional x-ro-validate-only argument. > > Right, a dry-run mode, makes sense. But strictly speaking, not a callback, right? (server doesn't invoke the client) > Re: the Google hackathon, was mostly a learning exercise for me, 1st time > > doing anything on Android. We got as far as having an app showing > entities, > > instances and instance details as retrieved from a back end application > via > > its REST API. Some screenshots in the slides from our end-of-hackathon > demo > > presentation. > > > > > That's a good result from just a weekend hacking, nice one. > Thanks - it made me have second thoughts on writing a native android client though. > > OK, what next? > > I am trying to carefully choose on what to put my time on. I would like to build something that can be used outside of the context of Cloudfier and Isis, and yet be useful in both contexts, so there are better chances of collaboration. Also, comparing to RO, Kirra looks almost like a client implementation, yet it has some differences, so I am conflicted between keeping working on it as is or aligning it with RO (I too have a REST-based to a Kirra-based back-end, see [5]). Also, if I take the non-native android client route, then it is so easy to consume JSON directly via HTTP in Javascript, that a client API such as what I started in [6] no longer seems that useful (what was driving me was the initial goal of building an Android client). So, the short answer is: I don't know yet. :) [4] https://bitbucket.org/abstratt/kirra-api/src/8f37ea9b18efd62de78de82c975046e62a313091/com.abstratt.kirra.api/src/com/abstratt/kirra/InstanceManagement.java?at=master#cl-112 [5] http://develop.cloudfier.com/services/api/demo-cloudfier-examples-expenses/instances/expenses.Employee/ [6] https://bitbucket.org/abstratt/kirra-api/src/master/com.abstratt.kirra.rest.client/src/com/abstratt/kirra/rest/client/ Thanks for the conversation! Rafael
