Quick immediate reply: > ~~~~~ > 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 > > * 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.
By the way: A DnD viewer can be later re-implemented, if so desired. > * 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 As described, this is a temporary state, with a future plan to later abstract out a new Objectstore API to support other objectstore frameworks. See below. > * Isis will adopt the Shiro authentication classes rather than define its > own. This will also allow authentication to be moved into the core. I have no comment :) > 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). The discussions I've had and heard regarding other application development suites lead me to believe that this would be an extremely useful add-on! I'd almost like to request that this be the first thing worked on, before any of the fundamental changes listed above. But that's just my wish. (I'd like to demo that Isis can also support RBAC, out-of-the-box). > > > 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. When the UI becomes user-configurable (re-arranged, pallete change, etc) this should be demo'd. Where are user preferences (e.g. UI language, timezone, etc) currently stored? Do we have demo code? > 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. > > > 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?) Thinking about it further, I would probably prefer to keep "Wicket" in the name somewhere, as the viewer *is* dependent on Wicket, and those who wish to extend (I want to add some additional view components), need to know Wicket. But I guess that other names may also be more appropriate.. > > 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. I agree and will try and step in more, here. > 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. I'll be in touch later for ideas for ApacheCon EU and other opportunities. Don't forget about opportunities to show off Isis in "rapid app" dev competitions. Jeroen, you mentioned one in the Netherlands?? Perhaps Isis can become the disruptive change from a surprising direction! > > ~~~ > 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 :) Unless otherwise indicated, I agree with the proposals.. ;) Regards, Kevin
