(replies inline) On Tue, 27 May 2014, Tom Fennelly wrote:
> Did you ever commit your experiments to GitHub? I'd be keen to see what > you did and would also be keen to hear your thoughts on the API and it's > suitability. I started a related thread (wasn't aware of this one until > now) at https://groups.google.com/forum/#!topic/jenkinsci-dev/zDaX4yiWLLw This fell off my queue of "things I have time to work on" so I never got around to it. The biggest challenge to the API work IMO is that it's currently not RESTful, and is quite difficult to make RESTful in a way that a Backbone collection can easily consume from. Part of the challenge is that Jenkins' datamodel is much more of a tree than most front-end toolkits are familiar with, but when you add added functionality from the plugins, modeling becomes extra tricky. I'm still of the opinion that a simple Backbone app + basic REST API exposing jobs, builds, basic details, would be more than enough for a large percentage of use-cases. Putting my code where my mouth is, isn't something I've had time for unfortunately. > On Monday, February 25, 2013 4:09:53 AM UTC, R Tyler Croy wrote: > > > > > > On Sat, 23 Feb 2013, Kohsuke Kawaguchi wrote: > > > > > Thanks for your thoughts. > > > > > > I actually think the abstraction behind how we expose data via JSON is > > > fundamentally sane --- it's basically the same object graph that the > > server > > > has, > > > > > > I think the problem you are seeing is that the default behavior of > > > "traverse this graph depth-first to the depth 1" isn't particularly > > useful. > > > Instead, you should use the tree parameter to select what portions of > > the > > > object graph you want to retrieve. > > > > > > I've been meaning to add the object graph navigator, and I think > > something > > > like that makes it clearer what the underlying data model is. > > > > > > Kohsuke and I spent a good deal of time talking in-person about this while > > we > > were at SCaLE11x this past weekend in LA. > > > > We've got a bit of a disagreement on how "suitable" the current API > > support is > > for building a JavaScript application atop Jenkins might be (for the > > record, I > > maintain that it is /not/ suitable :-P). > > > > Kohsuke brought up a good point about plugins, not regarding extending of > > the > > view, but rather how plugins would be plugging data into model objects > > such as > > "Build" or "Job" for the API. I'm not entirely certain the right direction > > on > > this, I'm hoping to find a good middle ground between the current API > > approach > > of plugins mixing data directly into models and providing their own API > > end-points separately which could lead to a plethora of HTTP requests from > > the > > UI app. > > > > I think the next step for my experimenting, which I'll have some time for > > next > > weekend, will be to sketch out what I think would be most suitable for an > > API > > after conferring with some of the guys I work with (this is literally what > > my > > team does). > > > > > > I'll update this thread once I have something on GitHub worth taking a > > gander > > at. > > > > > > Cheers > > - R. Tyler Croy > > -------------------------------------- > > Code: https://github.com/rtyler > > Chatter: https://twitter.com/agentdero > > > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. - R. Tyler Croy ------------------------------------------------------ Code: <https://github.com/rtyler> Chatter: <https://twitter.com/agentdero> % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F ------------------------------------------------------
pgpDziiA3sA37.pgp
Description: PGP signature
