On 17 June 2014 08:15, Stephen Cameron <[email protected]> wrote:
> Hi Dan, > > Just a thought bubble that the future is Web Components and maybe Angular > may or may not be compatible with that? > > Web components (polymer etc) is certainly promising, but given that Google is putting considerable resource behind both projects, I would be amazed if they don't converge. As I see it, AngularJS directives will be refactored into/replaced by web components; but much of the rest of Angular remains. Yhat said, I say this based on very little research, so happy to be corrected. > Personally I hope that the Application developers do get themselves sorted > with a good UI 'component object' approach and leave the REST to get on > with building a true 'web' outside of Facebook. > > +1 Dan > Steve Cameron > > > > On Mon, Jun 9, 2014 at 4:14 AM, Dan Haywood <[email protected]> > wrote: > > > Hi folks, > > > > On Friday and Saturday just gone a number of us - Jeroen, Oscar, > Maurizio, > > Kevin, Nacho and myself (5 committers and 1 non-committer) - met up in > > Milan for the first "IsisCon". Ok, not exactly a conference, but a great > > opportunity to see what we'd each been using Isis for, and to build a > > roadmap for Isis' future. There was also plenty of conversation about > > "marketing" Isis, in order to build up the user base. > > > > I believe we all came away the event feeling it had been extremely useful > > (as well as enjoyable), and I think there was a consensus on what that > > roadmap and respective priorities for Isis should be. > > > > That said, the "Apache way" is for such matters to be discussed on the > > mailing list: "if it isn't on the mailing list then it didn't happen". I > > therefore want to summarize the main topics of conversation that we had. > > > > For those who were in Milan: please amplify/extend/correct as necessary. > > For everyone else: please join in the conversation with your own > thoughts. > > Remember: we assume silent consensus. > > > > ~~~~~ > > Some of the ideas that follow build upon each other, some are independent > > of each other. I won't attempt to outline an exact timetable, but you > can > > see that some of this work could be performed in parallel. For example, > > improved Shiro support (4) could be done at the same time as simplifying > > the framework (1). > > > > 1. Simplifying the framework > > > > Apache Isis is the evolution of the original Naked Objects Framework for > > Java; when it entered the Apache incubator in 2010 the codebase was the > NOF > > code along with a number of "sister projects" that I had written over the > > previous few years. > > > > Some of this codebase is very old however - Rob Matthews (one of our > > committers) actually started on NOF in about 1999; 15 years ago! > > Obviously, since then a lot has changed, both in terms of the > > architectures we aim to support, and in other libraries/frameworks that > are > > available that we can leverage. > > > > For example, originally the NOF was intended to run either as standalone > > client, or in client/server mode, or as a server-only webapp. In Isis we > > retired the client/server remoting support when we graduated in 2012, but > > we still have the Drag-n-drop (DnD) viewer as a standalone Java AWT > viewer > > (even though this hasn't been released since we graduated the Apache > > incubator in 2012). > > > > Another change over the years is in persistence support. Isis has an > > ObjectStore API, and this allows different ObjectStore implementations to > > be plugged in. These include the JDO/Datanucleus ObjectStore, but also > the > > In-Memory ObjectStore, the XML ObjectStore and the NoSQL ObjectStore. > > (Again, these latter two have not been released since we graduated). > > > > While the JDO/Datanucleus ObjectStore manages (through the DataNucleus > ORM) > > its own lazy loading and dirty object tracking, the other ObjectStores do > > not have this ability; which means that the core-runtime component of the > > Isis framework must handle such matters instead. This introduces a lot > of > > complexity into Isis, as it must do many of the tasks that an ORM would > > normally do. > > > > Finally, another area where we have the opportunity to leverage third > party > > frameworks is in security. Isis defines its own authentication and > > authorization APIs, and these are exposed to the domain code in the > > DomainObjectContainer#getUser() method. Right now we have three such > > implementations - a simple file-based implementation, a do-nothing > "bypass" > > implementation, and an implementation based on Apache Shiro. > > > > So... we now feel the time is right to simplify: > > * Isis will run only as a server-side webapp. This implies that the DnD > > viewer will be retired. This will also enable Isis' bootstrapping to be > > simplified and rationalized. > > * Isis' current ObjectStore API will be removed, and the JDO/DataNucleus > > ObjectStore implementation then made part of core. The other ObjectStore > > implementations will be retired. This step in particular should enable > > considerable simplification > > * Isis will adopt the Shiro authentication classes rather than define its > > own. This will also allow authentication to be moved into the core. > > > > Each of these changes is relatively low risk, and introduces only minimal > > changes to existing domain code. In fact, hopefully only the change to > > authentication classes will require updates to existing code. The main > > intent is to throw away code that no longer provides any benefit, thus > > making it easier for others to learn a simplified Isis codebase. > > > > > > 2. JPA support > > > > Having simplified the codebase, the next step (so far as persistence is > > concerned) is to also support JPA. While DataNucleus is the reference > > implementation for JDO, we do recognize that most Java developers know > and > > therefore prefer JPA over JDO. Luckily DataNucleus does also support > JPA. > > Hopefully it will be easy enough to allow developers to use either API - > > JDO or JPA - with DataNucleus as the underlying implementation. > > > > > > 3. Alternative Persistence providers > > > > Having in (1) made Isis dependent on an ORM (for lazy loading and dirty > > object tracking) and on DataNucleus in particular, the next step in the > > roadmap is to re-introduce pluggability so that developers can use other > > ORM implementations; particularly for the JPA API. Being an Apache > product > > means that we cannot dependent on certain licenses, but we certainly > > provide alternative implemenation based on either Apache OpenJPA, or on > > EclipseLink (the old TopLink product). > > > > We might also look to provide an implementation for the market leader, > > namely Hibernate. However, because Hibernate is LGPL, this > implementation > > would need to live outside of Apache Isis' formal codebase, eg in the > > apache-extras.org site or perhaps just likely on github. > > > > > > 4. Improved support for Shiro > > > > We've noticed a number of users wanting to use our Shiro integration, > with > > Shiro configured to use a JDBC Realm. It ought to be relatively simple > to > > build Isis entities that map onto the Shiro concepts (users, roles, > > permissions). In this way Isis could provide a self-contained security > > subsystem for managing users "out-of-the-box". > > > > We anticipate delivering this as an optional module that could be > included > > as necessary. > > > > An extension of this is to deliver a standalone application built with > Isis > > for administrating the users/roles/permissions for any application > > configured to use the Shiro JDBC realm (not just an Isis application). > > > > > > 5. Other Reusable modules > > > > In the applib there are a number of services; some depend on parts of the > > Isis runtime; some do not. Some have their own entities, some do not: > > > > - CommandContext (applib implementation) > > - BackgroundService (core-runtime implementation) > > - BackgroundCommandService (JDO implementation, with entities) > > - AuditingService3 (JDO implementation, with entities) > > > > - PublishingService (JDO implementation, with entities) > > > > - ApplicationSettingsServiceRW (JDO implementation, with entities) > > - UserSettingsServiceRW (JDO implementation, with entities) > > > > - ClockService (applib implementation) > > - QueryResultsCache (applib implementation) > > - Scratchpad (applib implementation) > > > > - MementoService (core-runtime implementation) > > - BookmarkService (core-metamodel implementation) > > - XmlSnapshotService (core-runtime) > > - EventBus (core-runtime implementation) > > - ClassDiscoveryService (applib implementation, > > +optional org.reflections dependency) > > - WrapperFactory (core-wrapper) > > - DeveloperUtilitiesService (core-metamodel implementation) > > > > Extended the idea of the Shiro security module (4, above), we think it > > makes sense to modularize these other services; probably in five or so > > modules in line with the grouping shown above. That way developers could > > bring in a dependency to the services that they require, and ignore the > > others. > > > > > > 6. Profile Store > > > > The profile store is a component of the framework that is not supported > by > > either the Wicket or Restful Objects viewers, but whose functionality is > > broadly superceded by the UserSettingsService. > > > > In line with simplification (1) we'll retire this component. > > > > > > 7. Restful APIs > > > > The Restful Objects viewer implements the Restful Objects spec [2] and > > provides a full REST Hypermedia API to the Isis metamodel and runtime. > > > > The original intent of the RO spec/viewer was to provide a rich http/json > > API, rigorously following RESTful principles, to enable both the > > development of a "next-gen" generic viewer written in something like > > AngularJS [3], and also to enable bespoke REST applications to be > written. > > > > While we still feel that the RO viewer is appropriate for the former, > what > > is becoming more obvious is that the RO viewer is too complex for > > "idiomatic" RESTful access when using tools such as AngularJS and in > > particular higher-level lbraries such as Angular UI [4] > > > > We therefore have decided to: > > - rename the Restful Objects viewer, probably to be called the > "Hypermedia > > API" (remove the term "viewer") > > - implement a new "Idiomatic REST" API which - although not necessarily > > REST in the purist's sense - will play well with the aforementioned > tools. > > > > Many of the capabilities of the existing RO viewer can be leveraged to > > write this new Idiomatic REST API. But we do hope it will open up the > > possibilities of using Isis as a back-end to a new group of users. And, > an > > influx of new users might then lead in turn to the development of a > generic > > viewer against the "Hypermedia API". > > > > > > 8. Wicket Viewer > > > > We intend to continue developing the Wicket viewer. One part of its > > development will be to re-implement its components to use > Wicket-Bootstrap > > [5]; this will make it easier for its look-n-feel to be customised. > > > > We will also probably rename it. "Wicket" is merely the implementation > > technology; its name should represent what it's role is. Possible names > > are the "default viewer", or the "standard viewer" (preferences? > > alternatives?) > > > > > > > > 9. Community outreach > > > > In line with making Isis appeal to Javascript developers, we also want to > > make contact with the user communities of some of the technologies that > we > > use. > > > > Within Apache these include Wicket and Shiro. Meanwhile Oscar and > Nacho's > > application has a custom UI that leverages Wavemaker and React.js. > > > > Once we have the new "Idiomatic REST API" implemented, then opportunities > > open up to build demos to attract AngularJS and similar technologies (eg > > dhtmlx). > > > > > > > > 10. "framework" vs "platform" > > > > Although Isis was originally conceived as a framework - indeed, was > > originally named the Naked Objects Framework - the consensus in Milan was > > that it would be better to position Isis as a platform. Part of the > > rationale comes down with the way in which Isis is deployed, either > sitting > > on top of the JEE platform or Cloud platforms such as Google App Engine. > > > > > > 11. Better documentation, better website. > > > > Probably every open source project would wish for better documentation > and > > examples; we are no different, and we intend to keep improving the docs > and > > providing examples of usage. > > > > On the homepage one idea is to make Isis' value proposition more obvious. > > We intend to distinguish our audience, though; what a business person > > wants to know about is different from what a techie wants. So we will > > provide different material for each to consume. > > > > For a bit of interest/originality, Maurizio has offered to develop some > > goanimate [6] cartoon videos; he has used these with some success in his > > own software development company. Right now I am working on some scripts > > to be developed; one 2-minute business-focused one, and a number (3 or 4) > > of 2-minute technicaly focussed ones. > > > > Also, I am aware that much of the materials were written by me and all of > > the screencasts have my voice on them. But there should be other voices > > present on the website; Isis isn't a one-man show and visitors to the > > website shouldn't get that impression. > > > > > > 12. The great and the good > > > > With so many great open source projects out there it can of course be > > difficult to get heard and discovered. But if we can get some publicity > > and hopefully nice words/endorsements from the "great and the good", then > > that might well help increase our user base. > > > > Once we have updated the website a little (see 10) there are a few > > individuals we have in mind who we will look to contact. > > > > > > 13. Conferences, articles, podcasts > > > > Jeroen and I are intending to submitting a couple of sessions to > ApacheCon > > EU in Hungary [7], and in general try to do a few more sessions. > > > > I have also promised an 500-word blog post for Zeroturnaround to > advertise > > our JRebel integration. > > > > And, it'd also be good to do some podcasts sessions; I am sure they are > > several looking for new people to talk with. > > > > ~~~ > > > > As you'll have noticed, the last 4 or 5 topics fall broadly under the > > category of "marketing". So - if you've read this far - can I ask anyone > > and everyone in Isis to start help generate collateral. Blog posts (not > > just in the English language) are great; or ask (and self-answer) > questions > > on stackoverflow (with the #isis tag); or simply just send hints and tips > > on the mailing lists and I'll put them onto the website. > > > > ~~~ > > OK, I think that's it. > > > > As I say, for those who were in Milan, please amplify/expand/correct. > For > > everyone else, your comments/thoughts are welcome. > > > > Cheers > > Dan > > Apache Isis PMC Chair > > > > > > > > [1] http://semver.org > > [2] http://restfulobjects.org > > [3] http://angularjs.org/ > > [4] http://angular-ui.github.io/bootstrap > > [5] http://wb.agilecoders.de/demo/components > > [6] http://goanimate.com > > [7] http://www.apachecon.com/ > > >
