On Mar 20, 2007, at 9:26 AM, Venkata Krishnan wrote:
Hi Jeremy,
As part of this discussion and vote could we also summarize the
technical
reasons for each of us to be going one way or the other. Since
this is a
major decision point it would be good for everybody to know why we
as a
community are taking a specific direction and helps us to get back
to these
design decisions in the future whenever in doubt. I am really keen on
understanding each of our technical perspectives in this regard and
not
necessary in the context of weighing opinions for this vote.
I would too. We have actually had this discussion before, around this
time last year, and went with simple POJOs because they were easier
to use and did not require people to write several classes to wrap a
single field. The responsibility of conversion to/from XML was
treated as a problem for an XML binding and, at the time, the SDO
folk said they would look at a mechanism for loading user-supplied
POJOs (much like JAXB already allows).
Here is my attempt at this...
[X] +1 we should do this
[ ] -1 keep things as they are
My Reasons : (from whatever little I have been thro)
- I see that the interfaces will help us align better with the
assembly
model stated in the specs.
I agree we need to evolve the current model in line with the spec but
that is about model content and not about whether the model is
implemented as POJOs or interfaces. I wanted to keep discussion of
what we need to do to evolve the model separate from this discussion.
What is publicly available out of the model is
just about what is published in the interfaces and that is just
about what
the core (or extensions) should be using. Otherwise we might
encapsulate
into the model all that our core implementation would ideally need.
Also
basing the model on interfaces us flexibility in that while the
model's
implementation undergoes change the core that uses it continues
unaffected.
Thing is, there is no implementation in the model - it is a bunch of
simple POJO beans, structs with accessors (I consider set/get methods
as a syntactic convention). Interfaces have a role in abstracting
implementation but here there is no implementation to abstract.
But then we've been here before ...
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
