Sounds good! +1
I'd do 6 and 7 only if there is time left. This is quite a radical change, isn't? LieGrue, strub ----- Original Message ----- > From: Dan Haywood <[email protected]> > To: [email protected] > Cc: [email protected] > Sent: Wednesday, March 14, 2012 12:20 AM > Subject: plans for 0.3.0-incubating... > > All, > Just wanted to outline some of what I intend to work on for the next > release. Since some of this involves deleting (archiving off) code, this > is an opportunity to put forward an alternative view. > > 1. json viewer, implementing the Restful Objects spec. Nothing too > controversial here. I might rename it back to the "restful viewer", > though > (now that the xhtml-viewer is history). > > 2. bring in the JPA object store, ditching its reliance on Hibernate (not > compatible with ASF license policy) and replace with Apache's OpenJPA. > > 3. DELETE the dflt runtime's client/server remoting support. This has > never been used in anger in Isis (it was used on the original Naked Objects > framework, but only when running as a .NET app). If there ever were a > desire to reintroduce a client/server viewer, then the json/Restful API > will make a more than adequate replacement. > > 4. with remoting gone, simplify the dflt runtime's codebase. In > particular, the Persistor vs ObjectStore APIs can probably be simplified. > > 5. make OIDs fully self-describing, so that they identify the class as well > as the identity. When I look at the "real" objectstores (XML, SQL, > NoSQL, > JPA), they all do this anyway; the only one that doesn't is the in-memory > object store. Ideally we should be able to have a single Oid class (rather > than have every objectstore implementation define their own variant). > > 6. [A BIT MORE CONTROVERSIAL]: make OIDs immutable, and get rid of the idea > of OIDs knowing the state (persistent vs transient) of the object that they > identify. The main reason we have this is to support client/server > remoting, whereby an object starts off as transient when it leaves the > server, but when it comes back the OID needs to capture the fact that the > client wants it to be persisted. I'm not exactly sure what the final > design is here, but I'm pretty sure by moving some responsibilities about > subtly we should be able to make OIDs truly immutable. > > 7. Make HTML viewer stateless, for persistent objects at least. This > follows on from (6); it will also make it possible to develop on the HTML > viewer without having to logout/login on every deploy cycle (as we > currently have to do). > > ~~~ > I'll be making a start in the next couple of days on some of the > non-controversial stuff; shout out if any of the above concerns you. > > Dan >
