You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by Dan Haywood <da...@haywood-associates.co.uk> on 2012/03/14 00:20:34 UTC
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
Re: plans for 0.3.0-incubating...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 17 March 2012 10:53, Kevin Meyer - KMZ <ke...@kmz.co.za> wrote:
>
> One thing, though - as much as possible, please don't break database
> history, unless you have to - I have an app that uses the current
> database layout/values, and would prefer to not *have* to lock it to
> 0.2.0-incubating. But I will if that is what is required.
>
I suspect that the SQL object store will have the smallest number of issues
- at the end of the day the data is in tables, all that is changing is the
in-memory representation.
Where there could be bigger issues is with the xml object store and the
nosql object store, because there we take generate a string representation
of the Oid and write out to disk. But thinking it through, I suspect we
could write some reasonably simple code that would understand these
"legacy" on-disk formats and do an update on-the-fly as they need to.
Let me know if you think of anything else I should be aware of, though.
Cheers
Dan
>
> Regards,
> Kevin
>
>
>
Re: plans for 0.3.0-incubating...
Posted by Kevin Meyer - KMZ <ke...@kmz.co.za>.
Hi Dan,
I'm watching what you are doing, and suspect that other impacts can
also be managed.
Last year I created a new Isis objectstore stub that uses Cayenne for
read/write. I had to create an int / long Oid to blend Cayenne's oid with
Isis's oid. I'll re-examine that piece of work once you're done (I was
having to kludge oid sequencing to get Cayenne and Isis to agree /
use the same id for a given object).
Otherwise - I think I have a minor change on the sql-os that I need to
commit, then I can release it for you to mod to your hearts content.
(*commit done*)
One thing, though - as much as possible, please don't break database
history, unless you have to - I have an app that uses the current
database layout/values, and would prefer to not *have* to lock it to
0.2.0-incubating. But I will if that is what is required.
Regards,
Kevin
Re: plans for 0.3.0-incubating...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
All,
A quick status update on this work.
~~~
Done, and committed:
2a. @ObjectType and ObjectTypeFacet, plus JPA objectstore's metadata
Fallback impl for ObjectTypeFacet using fully qualified class name
enhance the reflector to hold a cache of ObjectType
3. delete the client/server remoting
~~~
In progress:
5a. Introduce a new Oid impl that has a serialized string format of
"ObjectType~Id", eg "CUS~123" or "com.mycompany.app.Order~123~456".
and 4 & 6. look to see what's left in terms of OIDs being immutable and
transient, and move responsibilities.
and 5b. Rework existing objectstores to use this new Oid impl
I spent much of yesterday working on the above. None of it is yet
committed, because I decided I'd need to break a few eggs to create this
particular omelette. But I want you to know what's going to be committed
in the next week or two. Also to ask please not to embark on any major
work in the area of the runtime and object stores.
~~~
Anyway, there were two sets of mutable methods on Oid:
- the getPrevious/hasPrevious/copyFrom methods
- the makePersistent method
Removing our client/server remoting meant the first set were able to be
removed.
The second, makePersistent(), was able to be made immutable by having it
take the new id as an arg, from which it returned a new Oid in persistent
state (but didn't change its own state). I then changed
AdapteManagerDefault#remapAsPersistent to replace the Oid for each adapter.
In other words, whereas previously the ObjectAdapter -> Oid was an
immutable reference to a mutable object, it is now a mutable reference to
an immutable one.
I also worked on getting a single Oid impl. Looking at the object stores,
we currently have:
* in-memory object store: uses SerialOid. This uses a long as its id, but
is not fully self-describing (it doesn't capture the object type). This
isn't a problem for the in-memory object store, because the objects never
need to be recreated
* xml object store: uses SerialOid, but when serializing out also writes
out the objectType in the XML
* nosql object store: uses its own NoSqlOid, that holds the classname and
then wraps a SerialOid to store the id
* sql object store: uses its own SqlOid, that holds the classname and also
a serializable PrimaryKey. In theory, it looks like the PrimaryKey is
polymorphic. In practice, though, it seemed that only an int could ever be
used.
I decided to steadily refactor the original SerialOid so that it would
support all object stores. I also decided that its id would be a simple
string, rather than an int or a long or something else. It then falls to
the OidGenerator impl (specific to each object store) to marshall the
Id/primary key/guid/whatever into a string format within the Oid. This
ended up allowing me to remove lots of test logic that had to know that a
SerialOid is normally formatted as a hexadecimal string, so I think it was
the right decision. It will also work well with the json/restful viewer,
once I get back to it.
So, where I am now is that there is a single Oid impl for root adapters.
The Oid hierarchy in total is as follows:
Oid
- AggregatedOid // pretty much unchanged
- RootOid // a new interface for root adapters
- RootOidDefault // what was SerialOid, now refactored
See the code listings of Oid and RootOid below for more info.
~~~
Next steps are to get the object stores properly working, and then to look
at the HTML and Scimpi viewers and see if they can be simplified.
One thing to note: the serialized format of Oids is different, meaning that
any existing data held in xml, nosql and (perhaps) sql object stores may
need to change. Not sure if we need to provide some sort of migration
script to do this. We can probably arrange that the serialized format is
the same as one of these (say, the nosql store) to minimize breakage. But
I'll need help from others to ensure we don't break stuff unnecessarily.
Dan
The Oid interface is:
/**
* An immutable identifier for either a root object (subtype {@link
RootOid}) or
* an aggregated object (subtype {@link AggregatedOid}).
*
* <p>
* Note that value objects (strings, ints, {@link Value}s etc) do not have
an {@link Oid}.
*/
public interface Oid {
/**
* A string representation of this {@link Oid}.
*
* <p>
* Note that {@link RootOid} provide a reciprocal static
<tt>deString</tt> method so that
* they can be round-tripped. However, this feature is not required or
provided by
* {@link AggregatedOid}.
*/
String enString();
/**
* Flags whether this OID is for a transient (not-yet-persisted) object.
*
* <p>
* In the case of an {@link AggregatedOid}, is determined by the state
* of its {@link AggregatedOid#getParentOid() parent}'s {@link
RootOid#isTransient() state}.
*/
boolean isTransient();
public static enum State {
PERSISTENT, TRANSIENT;
public boolean isTransient() {
return this == TRANSIENT;
}
}
}
while the RootOid is:
/**
* Defines a subtype of {@link Oid} specific to a root adapter.
*
* <p>
* The root adapter/pojo can be recreated with no further information; the
* {@link #getObjectType()} can be used to fetch the corresponding
* {@link ObjectSpecification} using {@link
SpecificationLoader#lookupByObjectType(String)}.
*
* <p>
* As such, is directly akin to the DSP's oid that is of the form
* <tt>CUS|1234567A</tt>, where the overall form is a simple string
* and also identifies the type of the object.
*
* <p>
* In addition, can be directly encoded/decoded into strings. The {@link
#enString()} interface
* is defined in the interface; implementations must also provide a static
* <tt>deString(String)</tt> factory method.
*/
public interface RootOid extends Oid {
String getObjectType();
String getIdentifier();
/**
* Returns a new RootOid for the same {@link #getObjectType()}, but
persistent and with the specified {@link #getIdentifier() identifier}.
*/
RootOid asPersistent(String identifier);
}
On 15 March 2012 15:26, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> Heh - I just got called on my remarks below via twitter.
>
> Characterizing Isis as a "UI-focused metamodel" was wrong of me; it is
> ultimately all about the domain model. But I guess when I wrote that I was
> just thinking about how Isis might come over to someone who's encountering
> the idea for the first time. A pure domain model is all very well, but
> it's somewhat theoretical - people like to see things, after all. (And
> those things they see had better be pretty... which is a whole other
> conversation....)
>
> Dan
>
>
> On 15 March 2012 10:22, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>> Hi Mark,
>>
>> You're right is quite a lot of work, but it's something I've been
>> thinking about for a very long while now. Right now Isis is too complex
>> and reinvents too many wheels. That's not a criticism - some of that code
>> was written before ORMs etc were mainstream. And quite a lot of that
>> complexity was to support requirements - specifically, client/server - that
>> just aren't mainstream anymore.
>>
>> Does any of this matter? Well, yes - I think that the complexity is
>> putting off would-be users of the framework, so it's something we need to
>> tackle.
>>
>> Ultimately I want to pare Isis down to its central "value add"; which is
>> basically a UI-focused metamodel with some viewers and a REST API that
>> expose it. And ultimately, I hope all this will be CDI beans to fit in
>> with JEE6/7, so it can be used in different contexts.
>>
>> This thread though, is the opportunity for anyone who wants to
>> refine/challenge that view.
>>
>> ~~~
>> In terms of an ordering of the steps that I outlined, it's actually as
>> follows:
>>
>> 2a. bring in the JPA objectstore's metadata - notably take creation of a
>> facet for @DiscriminatorValue and generalize this into an ObjectTypeFacet.
>> eg "CUS" is an abbreviation for com.mycompany.Customer. [I've started on
>> this already]
>>
>> write a default fallback impl of ObjectTypeFacet that would just use the
>> fully qualified class name as the "abbreviation".
>>
>> at same time, enhance the reflector to hold a cache of ObjectType
>>
>> 5a. Introduce a new Oid impl that has a serialized string format of
>> "ObjectType~Id", eg "CUS~123" or "com.mycompany.app.Order~123~456".
>>
>> 3. delete the remoting
>>
>> 4 & 6. look to see what's left in terms of OIDs being immutable and
>> transient, and move responsibilities.
>>
>> 5b. Rework existing objectstores to use this new Oid impl (and make
>> final, why not?)
>>
>> 7. make HTML viewer stateless
>>
>> 2b. Complete port of JPA object store to use the new Oid infra
>>
>> 1. Complete working on JSON viewer.
>>
>> Perhaps not all of that will make it into 0.3.0-incubating, but that's
>> the plan I intend to work to.
>>
>> ~~~
>> Please, all, let me know your thoughts; otherwise I'm assuming lazy
>> consensus.
>>
>> Dan
>>
>>
>>
>> ~~~~~~~~~~~~~
>>
>> On 15 March 2012 07:20, Mark Struberg <st...@yahoo.de> wrote:
>>
>>> 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 <da...@haywood-associates.co.uk>
>>> > To: isis-dev@incubator.apache.org
>>> > Cc: isis-users@incubator.apache.org
>>> > 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
>>> >
>>>
>>
>>
>
Re: plans for 0.3.0-incubating...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
All,
A quick status update on this work.
~~~
Done, and committed:
2a. @ObjectType and ObjectTypeFacet, plus JPA objectstore's metadata
Fallback impl for ObjectTypeFacet using fully qualified class name
enhance the reflector to hold a cache of ObjectType
3. delete the client/server remoting
~~~
In progress:
5a. Introduce a new Oid impl that has a serialized string format of
"ObjectType~Id", eg "CUS~123" or "com.mycompany.app.Order~123~456".
and 4 & 6. look to see what's left in terms of OIDs being immutable and
transient, and move responsibilities.
and 5b. Rework existing objectstores to use this new Oid impl
I spent much of yesterday working on the above. None of it is yet
committed, because I decided I'd need to break a few eggs to create this
particular omelette. But I want you to know what's going to be committed
in the next week or two. Also to ask please not to embark on any major
work in the area of the runtime and object stores.
~~~
Anyway, there were two sets of mutable methods on Oid:
- the getPrevious/hasPrevious/copyFrom methods
- the makePersistent method
Removing our client/server remoting meant the first set were able to be
removed.
The second, makePersistent(), was able to be made immutable by having it
take the new id as an arg, from which it returned a new Oid in persistent
state (but didn't change its own state). I then changed
AdapteManagerDefault#remapAsPersistent to replace the Oid for each adapter.
In other words, whereas previously the ObjectAdapter -> Oid was an
immutable reference to a mutable object, it is now a mutable reference to
an immutable one.
I also worked on getting a single Oid impl. Looking at the object stores,
we currently have:
* in-memory object store: uses SerialOid. This uses a long as its id, but
is not fully self-describing (it doesn't capture the object type). This
isn't a problem for the in-memory object store, because the objects never
need to be recreated
* xml object store: uses SerialOid, but when serializing out also writes
out the objectType in the XML
* nosql object store: uses its own NoSqlOid, that holds the classname and
then wraps a SerialOid to store the id
* sql object store: uses its own SqlOid, that holds the classname and also
a serializable PrimaryKey. In theory, it looks like the PrimaryKey is
polymorphic. In practice, though, it seemed that only an int could ever be
used.
I decided to steadily refactor the original SerialOid so that it would
support all object stores. I also decided that its id would be a simple
string, rather than an int or a long or something else. It then falls to
the OidGenerator impl (specific to each object store) to marshall the
Id/primary key/guid/whatever into a string format within the Oid. This
ended up allowing me to remove lots of test logic that had to know that a
SerialOid is normally formatted as a hexadecimal string, so I think it was
the right decision. It will also work well with the json/restful viewer,
once I get back to it.
So, where I am now is that there is a single Oid impl for root adapters.
The Oid hierarchy in total is as follows:
Oid
- AggregatedOid // pretty much unchanged
- RootOid // a new interface for root adapters
- RootOidDefault // what was SerialOid, now refactored
See the code listings of Oid and RootOid below for more info.
~~~
Next steps are to get the object stores properly working, and then to look
at the HTML and Scimpi viewers and see if they can be simplified.
One thing to note: the serialized format of Oids is different, meaning that
any existing data held in xml, nosql and (perhaps) sql object stores may
need to change. Not sure if we need to provide some sort of migration
script to do this. We can probably arrange that the serialized format is
the same as one of these (say, the nosql store) to minimize breakage. But
I'll need help from others to ensure we don't break stuff unnecessarily.
Dan
The Oid interface is:
/**
* An immutable identifier for either a root object (subtype {@link
RootOid}) or
* an aggregated object (subtype {@link AggregatedOid}).
*
* <p>
* Note that value objects (strings, ints, {@link Value}s etc) do not have
an {@link Oid}.
*/
public interface Oid {
/**
* A string representation of this {@link Oid}.
*
* <p>
* Note that {@link RootOid} provide a reciprocal static
<tt>deString</tt> method so that
* they can be round-tripped. However, this feature is not required or
provided by
* {@link AggregatedOid}.
*/
String enString();
/**
* Flags whether this OID is for a transient (not-yet-persisted) object.
*
* <p>
* In the case of an {@link AggregatedOid}, is determined by the state
* of its {@link AggregatedOid#getParentOid() parent}'s {@link
RootOid#isTransient() state}.
*/
boolean isTransient();
public static enum State {
PERSISTENT, TRANSIENT;
public boolean isTransient() {
return this == TRANSIENT;
}
}
}
while the RootOid is:
/**
* Defines a subtype of {@link Oid} specific to a root adapter.
*
* <p>
* The root adapter/pojo can be recreated with no further information; the
* {@link #getObjectType()} can be used to fetch the corresponding
* {@link ObjectSpecification} using {@link
SpecificationLoader#lookupByObjectType(String)}.
*
* <p>
* As such, is directly akin to the DSP's oid that is of the form
* <tt>CUS|1234567A</tt>, where the overall form is a simple string
* and also identifies the type of the object.
*
* <p>
* In addition, can be directly encoded/decoded into strings. The {@link
#enString()} interface
* is defined in the interface; implementations must also provide a static
* <tt>deString(String)</tt> factory method.
*/
public interface RootOid extends Oid {
String getObjectType();
String getIdentifier();
/**
* Returns a new RootOid for the same {@link #getObjectType()}, but
persistent and with the specified {@link #getIdentifier() identifier}.
*/
RootOid asPersistent(String identifier);
}
On 15 March 2012 15:26, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> Heh - I just got called on my remarks below via twitter.
>
> Characterizing Isis as a "UI-focused metamodel" was wrong of me; it is
> ultimately all about the domain model. But I guess when I wrote that I was
> just thinking about how Isis might come over to someone who's encountering
> the idea for the first time. A pure domain model is all very well, but
> it's somewhat theoretical - people like to see things, after all. (And
> those things they see had better be pretty... which is a whole other
> conversation....)
>
> Dan
>
>
> On 15 March 2012 10:22, Dan Haywood <da...@haywood-associates.co.uk> wrote:
>
>> Hi Mark,
>>
>> You're right is quite a lot of work, but it's something I've been
>> thinking about for a very long while now. Right now Isis is too complex
>> and reinvents too many wheels. That's not a criticism - some of that code
>> was written before ORMs etc were mainstream. And quite a lot of that
>> complexity was to support requirements - specifically, client/server - that
>> just aren't mainstream anymore.
>>
>> Does any of this matter? Well, yes - I think that the complexity is
>> putting off would-be users of the framework, so it's something we need to
>> tackle.
>>
>> Ultimately I want to pare Isis down to its central "value add"; which is
>> basically a UI-focused metamodel with some viewers and a REST API that
>> expose it. And ultimately, I hope all this will be CDI beans to fit in
>> with JEE6/7, so it can be used in different contexts.
>>
>> This thread though, is the opportunity for anyone who wants to
>> refine/challenge that view.
>>
>> ~~~
>> In terms of an ordering of the steps that I outlined, it's actually as
>> follows:
>>
>> 2a. bring in the JPA objectstore's metadata - notably take creation of a
>> facet for @DiscriminatorValue and generalize this into an ObjectTypeFacet.
>> eg "CUS" is an abbreviation for com.mycompany.Customer. [I've started on
>> this already]
>>
>> write a default fallback impl of ObjectTypeFacet that would just use the
>> fully qualified class name as the "abbreviation".
>>
>> at same time, enhance the reflector to hold a cache of ObjectType
>>
>> 5a. Introduce a new Oid impl that has a serialized string format of
>> "ObjectType~Id", eg "CUS~123" or "com.mycompany.app.Order~123~456".
>>
>> 3. delete the remoting
>>
>> 4 & 6. look to see what's left in terms of OIDs being immutable and
>> transient, and move responsibilities.
>>
>> 5b. Rework existing objectstores to use this new Oid impl (and make
>> final, why not?)
>>
>> 7. make HTML viewer stateless
>>
>> 2b. Complete port of JPA object store to use the new Oid infra
>>
>> 1. Complete working on JSON viewer.
>>
>> Perhaps not all of that will make it into 0.3.0-incubating, but that's
>> the plan I intend to work to.
>>
>> ~~~
>> Please, all, let me know your thoughts; otherwise I'm assuming lazy
>> consensus.
>>
>> Dan
>>
>>
>>
>> ~~~~~~~~~~~~~
>>
>> On 15 March 2012 07:20, Mark Struberg <st...@yahoo.de> wrote:
>>
>>> 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 <da...@haywood-associates.co.uk>
>>> > To: isis-dev@incubator.apache.org
>>> > Cc: isis-users@incubator.apache.org
>>> > 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
>>> >
>>>
>>
>>
>
Re: plans for 0.3.0-incubating...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Heh - I just got called on my remarks below via twitter.
Characterizing Isis as a "UI-focused metamodel" was wrong of me; it is
ultimately all about the domain model. But I guess when I wrote that I was
just thinking about how Isis might come over to someone who's encountering
the idea for the first time. A pure domain model is all very well, but
it's somewhat theoretical - people like to see things, after all. (And
those things they see had better be pretty... which is a whole other
conversation....)
Dan
On 15 March 2012 10:22, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> Hi Mark,
>
> You're right is quite a lot of work, but it's something I've been thinking
> about for a very long while now. Right now Isis is too complex and
> reinvents too many wheels. That's not a criticism - some of that code was
> written before ORMs etc were mainstream. And quite a lot of that
> complexity was to support requirements - specifically, client/server - that
> just aren't mainstream anymore.
>
> Does any of this matter? Well, yes - I think that the complexity is
> putting off would-be users of the framework, so it's something we need to
> tackle.
>
> Ultimately I want to pare Isis down to its central "value add"; which is
> basically a UI-focused metamodel with some viewers and a REST API that
> expose it. And ultimately, I hope all this will be CDI beans to fit in
> with JEE6/7, so it can be used in different contexts.
>
> This thread though, is the opportunity for anyone who wants to
> refine/challenge that view.
>
> ~~~
> In terms of an ordering of the steps that I outlined, it's actually as
> follows:
>
> 2a. bring in the JPA objectstore's metadata - notably take creation of a
> facet for @DiscriminatorValue and generalize this into an ObjectTypeFacet.
> eg "CUS" is an abbreviation for com.mycompany.Customer. [I've started on
> this already]
>
> write a default fallback impl of ObjectTypeFacet that would just use the
> fully qualified class name as the "abbreviation".
>
> at same time, enhance the reflector to hold a cache of ObjectType
>
> 5a. Introduce a new Oid impl that has a serialized string format of
> "ObjectType~Id", eg "CUS~123" or "com.mycompany.app.Order~123~456".
>
> 3. delete the remoting
>
> 4 & 6. look to see what's left in terms of OIDs being immutable and
> transient, and move responsibilities.
>
> 5b. Rework existing objectstores to use this new Oid impl (and make final,
> why not?)
>
> 7. make HTML viewer stateless
>
> 2b. Complete port of JPA object store to use the new Oid infra
>
> 1. Complete working on JSON viewer.
>
> Perhaps not all of that will make it into 0.3.0-incubating, but that's the
> plan I intend to work to.
>
> ~~~
> Please, all, let me know your thoughts; otherwise I'm assuming lazy
> consensus.
>
> Dan
>
>
>
> ~~~~~~~~~~~~~
>
> On 15 March 2012 07:20, Mark Struberg <st...@yahoo.de> wrote:
>
>> 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 <da...@haywood-associates.co.uk>
>> > To: isis-dev@incubator.apache.org
>> > Cc: isis-users@incubator.apache.org
>> > 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
>> >
>>
>
>
Re: plans for 0.3.0-incubating...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Heh - I just got called on my remarks below via twitter.
Characterizing Isis as a "UI-focused metamodel" was wrong of me; it is
ultimately all about the domain model. But I guess when I wrote that I was
just thinking about how Isis might come over to someone who's encountering
the idea for the first time. A pure domain model is all very well, but
it's somewhat theoretical - people like to see things, after all. (And
those things they see had better be pretty... which is a whole other
conversation....)
Dan
On 15 March 2012 10:22, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> Hi Mark,
>
> You're right is quite a lot of work, but it's something I've been thinking
> about for a very long while now. Right now Isis is too complex and
> reinvents too many wheels. That's not a criticism - some of that code was
> written before ORMs etc were mainstream. And quite a lot of that
> complexity was to support requirements - specifically, client/server - that
> just aren't mainstream anymore.
>
> Does any of this matter? Well, yes - I think that the complexity is
> putting off would-be users of the framework, so it's something we need to
> tackle.
>
> Ultimately I want to pare Isis down to its central "value add"; which is
> basically a UI-focused metamodel with some viewers and a REST API that
> expose it. And ultimately, I hope all this will be CDI beans to fit in
> with JEE6/7, so it can be used in different contexts.
>
> This thread though, is the opportunity for anyone who wants to
> refine/challenge that view.
>
> ~~~
> In terms of an ordering of the steps that I outlined, it's actually as
> follows:
>
> 2a. bring in the JPA objectstore's metadata - notably take creation of a
> facet for @DiscriminatorValue and generalize this into an ObjectTypeFacet.
> eg "CUS" is an abbreviation for com.mycompany.Customer. [I've started on
> this already]
>
> write a default fallback impl of ObjectTypeFacet that would just use the
> fully qualified class name as the "abbreviation".
>
> at same time, enhance the reflector to hold a cache of ObjectType
>
> 5a. Introduce a new Oid impl that has a serialized string format of
> "ObjectType~Id", eg "CUS~123" or "com.mycompany.app.Order~123~456".
>
> 3. delete the remoting
>
> 4 & 6. look to see what's left in terms of OIDs being immutable and
> transient, and move responsibilities.
>
> 5b. Rework existing objectstores to use this new Oid impl (and make final,
> why not?)
>
> 7. make HTML viewer stateless
>
> 2b. Complete port of JPA object store to use the new Oid infra
>
> 1. Complete working on JSON viewer.
>
> Perhaps not all of that will make it into 0.3.0-incubating, but that's the
> plan I intend to work to.
>
> ~~~
> Please, all, let me know your thoughts; otherwise I'm assuming lazy
> consensus.
>
> Dan
>
>
>
> ~~~~~~~~~~~~~
>
> On 15 March 2012 07:20, Mark Struberg <st...@yahoo.de> wrote:
>
>> 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 <da...@haywood-associates.co.uk>
>> > To: isis-dev@incubator.apache.org
>> > Cc: isis-users@incubator.apache.org
>> > 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
>> >
>>
>
>
Re: plans for 0.3.0-incubating...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Mark,
You're right is quite a lot of work, but it's something I've been thinking
about for a very long while now. Right now Isis is too complex and
reinvents too many wheels. That's not a criticism - some of that code was
written before ORMs etc were mainstream. And quite a lot of that
complexity was to support requirements - specifically, client/server - that
just aren't mainstream anymore.
Does any of this matter? Well, yes - I think that the complexity is
putting off would-be users of the framework, so it's something we need to
tackle.
Ultimately I want to pare Isis down to its central "value add"; which is
basically a UI-focused metamodel with some viewers and a REST API that
expose it. And ultimately, I hope all this will be CDI beans to fit in
with JEE6/7, so it can be used in different contexts.
This thread though, is the opportunity for anyone who wants to
refine/challenge that view.
~~~
In terms of an ordering of the steps that I outlined, it's actually as
follows:
2a. bring in the JPA objectstore's metadata - notably take creation of a
facet for @DiscriminatorValue and generalize this into an ObjectTypeFacet.
eg "CUS" is an abbreviation for com.mycompany.Customer. [I've started on
this already]
write a default fallback impl of ObjectTypeFacet that would just use the
fully qualified class name as the "abbreviation".
at same time, enhance the reflector to hold a cache of ObjectType
5a. Introduce a new Oid impl that has a serialized string format of
"ObjectType~Id", eg "CUS~123" or "com.mycompany.app.Order~123~456".
3. delete the remoting
4 & 6. look to see what's left in terms of OIDs being immutable and
transient, and move responsibilities.
5b. Rework existing objectstores to use this new Oid impl (and make final,
why not?)
7. make HTML viewer stateless
2b. Complete port of JPA object store to use the new Oid infra
1. Complete working on JSON viewer.
Perhaps not all of that will make it into 0.3.0-incubating, but that's the
plan I intend to work to.
~~~
Please, all, let me know your thoughts; otherwise I'm assuming lazy
consensus.
Dan
~~~~~~~~~~~~~
On 15 March 2012 07:20, Mark Struberg <st...@yahoo.de> wrote:
> 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 <da...@haywood-associates.co.uk>
> > To: isis-dev@incubator.apache.org
> > Cc: isis-users@incubator.apache.org
> > 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
> >
>
Re: plans for 0.3.0-incubating...
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Mark,
You're right is quite a lot of work, but it's something I've been thinking
about for a very long while now. Right now Isis is too complex and
reinvents too many wheels. That's not a criticism - some of that code was
written before ORMs etc were mainstream. And quite a lot of that
complexity was to support requirements - specifically, client/server - that
just aren't mainstream anymore.
Does any of this matter? Well, yes - I think that the complexity is
putting off would-be users of the framework, so it's something we need to
tackle.
Ultimately I want to pare Isis down to its central "value add"; which is
basically a UI-focused metamodel with some viewers and a REST API that
expose it. And ultimately, I hope all this will be CDI beans to fit in
with JEE6/7, so it can be used in different contexts.
This thread though, is the opportunity for anyone who wants to
refine/challenge that view.
~~~
In terms of an ordering of the steps that I outlined, it's actually as
follows:
2a. bring in the JPA objectstore's metadata - notably take creation of a
facet for @DiscriminatorValue and generalize this into an ObjectTypeFacet.
eg "CUS" is an abbreviation for com.mycompany.Customer. [I've started on
this already]
write a default fallback impl of ObjectTypeFacet that would just use the
fully qualified class name as the "abbreviation".
at same time, enhance the reflector to hold a cache of ObjectType
5a. Introduce a new Oid impl that has a serialized string format of
"ObjectType~Id", eg "CUS~123" or "com.mycompany.app.Order~123~456".
3. delete the remoting
4 & 6. look to see what's left in terms of OIDs being immutable and
transient, and move responsibilities.
5b. Rework existing objectstores to use this new Oid impl (and make final,
why not?)
7. make HTML viewer stateless
2b. Complete port of JPA object store to use the new Oid infra
1. Complete working on JSON viewer.
Perhaps not all of that will make it into 0.3.0-incubating, but that's the
plan I intend to work to.
~~~
Please, all, let me know your thoughts; otherwise I'm assuming lazy
consensus.
Dan
~~~~~~~~~~~~~
On 15 March 2012 07:20, Mark Struberg <st...@yahoo.de> wrote:
> 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 <da...@haywood-associates.co.uk>
> > To: isis-dev@incubator.apache.org
> > Cc: isis-users@incubator.apache.org
> > 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
> >
>
Re: plans for 0.3.0-incubating...
Posted by Mark Struberg <st...@yahoo.de>.
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 <da...@haywood-associates.co.uk>
> To: isis-dev@incubator.apache.org
> Cc: isis-users@incubator.apache.org
> 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
>