Hi Dan and others, I think this is a really good start for some changes in ISIS. Coming from another Apache full-stack business app oriented framework (Apache OFBiz) I find ISIS really interesting.
Personally after reading the NO book and going through the examples, I found it hard to dive deeper into the framework, many viewers and deployment models... made it hard to focus on and understand the core functionality of the framework. So I strongly support the cleanup of the viewers and having in the base framework only the best (full and clean) implemented one as a reference. Another thing is that ISIS is a full-stack framework and not simply a tool which can be used as part of another project or development process, thus make it hard to use in real life projects. some other notes: I couldn't see a list(jira filter) for issues that can be fixed by newcomers. A running demo on Apache infrastucture would be good demonstration of ISIS features. I heard about ISIS on last year's LJC Open Conference. Giving a 5min lightening talk about ISIS on LJC gatherings would be helpful too. Cheers, Bilgin Ibryam On 21 November 2011 13:02, Dan Haywood <[email protected]> wrote: > There's been an interesting thread going on in [email protected] [1] about (a) > the number of podlings in the incubator and (b) how long some of them are > taking to graduate. One of the main points being made is that podlings that > have been in the incubator for a certain period of time (no-one is > suggesting how long exactly, but 1 year is being used as a strawman in the > thread) should be more explicit in defining their roadmap and action steps > towards graduation. > > To be honest, this is all very reasonable, but from Isis' point of view it > is perhaps slightly worrying, because although we've made some progress with > getting our code etc together (and the licenses, ICLAs, release processes > etc are in good shape), we haven't made a lot of progress in attracting new > committers. Indeed, arguably we've gone backwards in that space: right now > only Kevin, Rob and myself currently actively commit. > > With that in mind, Kevin, Rob and I had a skype conf call this weekend to > discuss some ideas to move Isis forward towards graduation. Obviously, this > is it's slightly against Apache policy ("if it didn't happen on the mailing > list then it didn't happen"), which is why I'm posting here now to post some > of our initial conclusions and to broaden out the discussion to everyone > else who might be interested. (Kevin and Rob: correct me if I overstate on > any of this). > > > Marketing Message > > The main thing we discussed was the "marketing message" for Isis. > > Automatic UI > > The view we came to was that the automatic-UI generation part of Isis (ie > the naked objects pattern) is possibly more of a negative than a positive, > at least so far as attracting new users: > * That is, for those that have heard of naked objects (guestimate: 1/4 to > 1/3 of developers), chances are that they have dismissed it as being a way > to build over-simplified CRUD-style applications. (Of course, those of us > who have actually used it to build apps know that ain't so, but that's a > different discussion). > * For those that have not heard of naked objects, the proposition that > "here's a framework that will automatically generate your UIs" doesn't > resonate. Why? I guess we can speculate; my view is that there are now > plenty of UI technologies that are quite productive/easy to use/fun; > probably a lot more so than when the original naked objects framework was > developed c: 2000. Another reason might be that developers put too much > emphasis over owning the UI rather than making sure the domain model is > good. > > On the other hand, we did conclude that the automatic-UI is useful as a > design tool, and would-be users of Isis could probably understand it in > those terms. The fact that the automatic UI is also suitable for use by > end-users in some situations is subsidiary and something that adopters of > Isis might discover only later on. > > REST > > Another point that I was keen to see factored into the marketing message for > Isis is its REST support (the json-viewer). As you may have picked up from > other posts, I've been developing a standalone spec, Restful Objects [2], > which defines defines a set of RESTful resources, and corresponding JSON > representations, for accessing and manipulating a domain object model. > > I'm quite excited by this Restful stuff. On the one hand, as well as Isis' > implementation, there's also another .NET implementation underway via Naked > Objects MVC (Richard Pawson has been providing great feedback on the spec). > And Johan Andries has been making good progress on a new RESTful UI, which > I'm hoping might go open source. Also, the REST approach has met a good > reaction at our (joint) client in Ireland. > > In terms of marketing, my view is that REST is an area where there is > currently a lot of interest, but developers looking into it will likely > realise that it's a complex area to do right (ful support for HATEOAS, HTTP > headers and status codes etc). As such, developers might be interested in a > framework that can help them out, at a somewhat higher level of abstraction > than JSR-311. The proposition is: press a button and get a complete, fully > restful API to any domain model. > > DDD > > A third message is for those that are interested in domain modelling/domain > driven design, for whom the automatic UI might (again) be a useful design > tool who might want to deploy their app on some other framework, eg Spring > or JEE. > > So, overall this gives us three target use cases to address. The view we > took on was that the home page should reflect these use cases: > - domain modelling (and deploy on own platform) > - REST > - automatically generated webapp (primarily to support the other two use > cases, but optionally as a deployment in its own right) > > With this in mind I've sketched up a new graphic that could be used for the > home page, see [3]. The current home page (the hexagonal architecture) > would probably be demoted to a supporting page describing the architecture > of Isis. > > In addition, we thought that the side bar menu should be restructured around > these use cases. > > > Alpha status viewers > > Another point we discussed was the incomplete nature of some of the > viewers. Having would-be users come across code that is broken is clearly > not a good experience, at least if there expectations are that everything > works. > > Specifically: > * the scimpi viewer is code complete but its supporting documentation is > incomplete > * the wicket viewer is not complete (though it's documentation is pretty > good!) > * the xhtml viewer (which is a precursor to the json viewer, but using XHTML > representations) is superceded by the json viewer and so should be removed > * the dnd viewer (which has worked in the past), is currently broken > (doesn't repaint properly) > > We discussed the dnd viewer quite a lot. Although it is, in some sense, the > "purest" expression of the naked objects pattern (bringing in some of the > original ideas of expressive systems), the truth, probably, is that for our > target audience this isn't important to emphasise. Crudely put: would-be > users are not going to understand what the somewhat unconventionaly UI that > the dnd browser provides is trying to achieve. The fact that it is > currently broken hardly helps atters. > > So one of the points we thought made sense was to change things so that the > HTML viewer is the default, rather than DnD. > > In terms of the documentation and the site, we decided that the web site > pages for the scimpi, wicket and dnd viewers should indicate that they are > "alpha" status, and on the left hand menu we should group them under "other > viewers". As such, we probably should remove them from the Maven archetype > until such time that they are back to production quality. > > > Remoting > > We also discussed the remoting component. The remoting component enables > the dnd viewer to be deployed in a client/server configuration, and is what > is used in the big Irish project (on the old .NET version of the naked > objects framework). However, my personal view is that remoting is, well, > broken. In fact, I think it should be removed: (a) the caching semantics > for client-side domain objects is not well-defined; (b) anyone wanting a > client/server solution would probably look towards an approach that uses > REST, (c) the remoting support introduces a lot of complexity in the default > runtime (notably, the separation of the "Persistor" API and the > "ObjectStore" API). > > However, we didn't necessarily all agree on this viewpoint. So for now, we > decided to de-emphasise remoting, because it doesn't fit into the 3 main use > cases that we highlighted above. That means that it won't appear in the > left-hand menu, for example. My suggestion is that we link to it from the > dnd viewer page (because that's the only viewer that would make use of it). > > > Release > > Kevin has been working through the release procedures that I documented, and > made some changes and clarifications. I think that by-and-large they are > holding up ok. > > I offered to push out a new release, because we are well overdue for another > release. I propose to do this once we've restructured the site a little > (assuming that we go with the ideas I'm summarizing in this thread). > > > Blogging > > In terms of building up a community, I suggested that we need to be more > organized about blogging. A little organization here between the > contributors could substantially increase Isis' reach: > > * one idea is that Rob, Kevin and I take it in turns to publish a blog post > such that there is at least one new blog post every week > * blog posts should also be cross posted to blogs.apache.org (which will hit > some other aggregators) > * publicise blog posts in twitter using #apache #isis hashtags > * publicise blog posts via dzone.com (and any other places you might choose) > * publicise blog posts via isis-dev mailing list, and ask others to up-vote > in dzone). > > In terms of content, one question raised was what, exactly, to blog about. > My thoughts are: > * choose a theme for a series of blogs: > - eg tips-n-tricks taken from applications working on (Robert's > PlanChaser, or Kevin's various apps) > - copy-n-paste some of the sidebars from the Richard/Robert's original > Naked Objects book (for Robert) > - work through some of the applib conventions, eg how to do choices for a > property. > > In terms of "how to": > * keep it short, something that won't take more than 2 or 3 minutes to read > * if you have more than that, then leave it to the next part > * sit down and write 2 or 3 posts at a time (or split up a draft blog post > that's got too long) and then only publish them according to a schedule > > > Articles > > Rob, Kevin and I didn't discuss writing articles in our call; clearly some > articles would be good (eg infoq.com or theserverside.com), but it takes > that much more time to do. I'd rather focus on just getting a steady stream > of blog posts going first. > > > Thoughts? > > OK, I think that more or less summarises the points that I wanted to raise. > If anyone has any views on this/clarifications/corrections, then post them > here. > > Meantime, I intend to put some additional material on blogging up onto our > wiki. > > > Thanks, > Dan > > [1] http://osdir.com/ml/general.incubator.apache.org/2011-11/msg00182.html > [2] http://restfulobjects.org/ > [3] https://cwiki.apache.org/confluence/display/ISIS/RevampedSiteIdeas
