[Geoserver-devel] GSIP 52 - Catalog / Config DAO Refactor - Call for Vote

Hi all,

I am not sure if i made it clear when i posted the GSIP last week but i would like to move it forward through voting. So far I have no votes on this proposal from any PSC members.

Thanks.

-Justin


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

On Tue, Oct 19, 2010 at 3:54 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
I am not sure if i made it clear when i posted the GSIP last week but i
would like to move it forward through voting. So far I have no votes on this
proposal from any PSC members.

Hey there... sorry for not replying, I did not do because I did not find
an easy to review the proposal, so I guessed I had to actually read the patch
line by line to figure it out.

I see the new interfaces (one is without javadoc comments btw) and I had
a quick look at the code but the structure of the changes escapes me when
just glancing at the code.
(btw, why is every access to the DAO synchronized inside the catalog,
would it be the same
to have the dao implementor synchronize every method if the dao is
not thread safe?)

I won't have time to really look into the diffs until next weekend, I
guess having
a bit more of description would expedite the review (things like the
dao synch above for example).
You know, something that sits in the middle between "let's have a DAO approach"
and actually going line by line through the patch.

But if you can wait till the weekend I can actually sit down head
clear and look into
it for good as is, without any change or extra description.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

Hi Justin,

that's really nice, it looks like the changes we've been discussing a while
ago are taking their way into Geoserver :slight_smile:
As read in a previous email of yours, the interfaces are very close to the
ones I proposed. Andrea, I guess you may refer to some docs here:
   JIRA: Catalog+DAO split:
   http://jira.codehaus.org/browse/GEOS-3806
and here
  R’n’D: Catalog+DAO refactoring:
  http://geoserver.org/pages/viewpage.action?pageId=22708796

We may then want to extend such interfaces with paginated calls in order to
improve access in big catalogs. I know that such a change is not fully
backward compatible, but I wonder if it is in your plans.

   Ciao,
   Emanuele

Alle 17:45:19 di martedì 19 ottobre 2010, Andrea Aime ha scritto:

On Tue, Oct 19, 2010 at 3:54 PM, Justin Deoliveira <jdeolive@anonymised.com>

wrote:

> Hi all,
> I am not sure if i made it clear when i posted the GSIP last week but i
> would like to move it forward through voting. So far I have no votes on
> this proposal from any PSC members.

Hey there... sorry for not replying, I did not do because I did not find
an easy to review the proposal, so I guessed I had to actually read the
patch line by line to figure it out.

I see the new interfaces (one is without javadoc comments btw) and I had
a quick look at the code but the structure of the changes escapes me when
just glancing at the code.
(btw, why is every access to the DAO synchronized inside the catalog,
would it be the same
to have the dao implementor synchronize every method if the dao is
not thread safe?)

I won't have time to really look into the diffs until next weekend, I
guess having
a bit more of description would expedite the review (things like the
dao synch above for example).
You know, something that sits in the middle between "let's have a DAO
approach" and actually going line by line through the patch.

But if you can wait till the weekend I can actually sit down head
clear and look into
it for good as is, without any change or extra description.

Cheers
Andrea

-----------------------------------------------------
Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-----------------------------------------------------

---------------------------------------------------------------------------
--- Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

-------------------------------------------------------
Ing. Emanuele Tajariol

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com
-------------------------------------------------------

I guess I should have specified it more. Although historically there has been much discussion about these issues and this approach back when geosolutions took this on. But I am happy to clarify anything in particular and if you can narrow down what I should document in more detail I am happy to do so.

On Tue, Oct 19, 2010 at 9:45 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Oct 19, 2010 at 3:54 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
I am not sure if i made it clear when i posted the GSIP last week but i
would like to move it forward through voting. So far I have no votes on this
proposal from any PSC members.

Hey there… sorry for not replying, I did not do because I did not find
an easy to review the proposal, so I guessed I had to actually read the patch
line by line to figure it out.

I see the new interfaces (one is without javadoc comments btw) and I had
a quick look at the code but the structure of the changes escapes me when
just glancing at the code.
(btw, why is every access to the DAO synchronized inside the catalog,
would it be the same
to have the dao implementor synchronize every method if the dao is
not thread safe?)

I don’t think every access to the dao is synchronized. Only ones that have to do multiple related operations. Like for instance removing a workspace or adding a workspace also has the side affect of setting the default workspace if it is not set. Within the old catalog implementation access to the workspace was synchronized for this transaction.

The first priority in my mind is backwards compatibility, so i kept things as close to the way they were before as possible. However i realize this is an issue. But its one I think that will have to be solved incrementally. Perhaps we need the notion of a transaction? Not too sure.

I won’t have time to really look into the diffs until next weekend, I
guess having
a bit more of description would expedite the review (things like the
dao synch above for example).

You know, something that sits in the middle between “let’s have a DAO approach”
and actually going line by line through the patch.

Ok… i am not exactly sure what that is… perhaps going through the old email archives and jira issue discussions for context would help?

But if you can wait till the weekend I can actually sit down head
clear and look into
it for good as is, without any change or extra description.

Sure that is fine. And if all is the same I prefer that someone review the patch in detail rather than I go through and try to document and summarize all the implementation details. But for things that people want more explanation for i am happy to do so.

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Also in case you missed the email i sent a couple of weeks ago i did acutally try to summarize the main parts of the patch. Here it is just in case:

So the patch as you can imagine is rather large. But I will summarize the main points of it here:

  1. CatalogDAO and GeoServer DAO interfaces created, with DefaultCatalogDAO and DefaultGeoServerDAO as default implementations respectively
  2. Data access code factored out of CatalogImpl and GeoServerImpl and put into the default daos
  3. Some minor catalog/config bean tweaks, implementing equals()/hashcode(), adding default constructors, etc…
  4. GeoServerLoader refactored to allow for subclasses to override startup loading behaviour. GeoServerLoaderProxy is not registered with spring and loads a GeoServerLoader
    instance based on the spring configuration, falling back on DefaultGeoServerLoader which implements the default startup we have today
  5. XStreamPersister modified to handle different implementations of List, Set, etc… For instance in cases such as hibernate that creates custom collections. It know is lax and
    simply works against the Collection interfaces not worrying about specific implementations of a collection
  6. GeoServerTestSupport modified to reflect the changes made to GeoServerLoader
  7. GeoServerImplTest and CatalogImplTest modified to allow for subclases. Also removed some bad assumptions that assumed an in memory implementation of the catalog/config

On Tue, Oct 19, 2010 at 9:45 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Oct 19, 2010 at 3:54 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi all,
I am not sure if i made it clear when i posted the GSIP last week but i
would like to move it forward through voting. So far I have no votes on this
proposal from any PSC members.

Hey there… sorry for not replying, I did not do because I did not find
an easy to review the proposal, so I guessed I had to actually read the patch
line by line to figure it out.

I see the new interfaces (one is without javadoc comments btw) and I had
a quick look at the code but the structure of the changes escapes me when
just glancing at the code.
(btw, why is every access to the DAO synchronized inside the catalog,
would it be the same
to have the dao implementor synchronize every method if the dao is
not thread safe?)

I won’t have time to really look into the diffs until next weekend, I
guess having
a bit more of description would expedite the review (things like the
dao synch above for example).
You know, something that sits in the middle between “let’s have a DAO approach”
and actually going line by line through the patch.

But if you can wait till the weekend I can actually sit down head
clear and look into
it for good as is, without any change or extra description.

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Thanks Emanuele, this comes out of the great work that you did so thank you :slight_smile:

About paging, yes it is in the plans. As I described in detail in an email to the developer list a few weeks go [1] this current patch is level 0. The very basics to get the hibernate catalog working in a way that does not totally disrupt the existing code base.

The next step is to modify the catalog interface to support a notion of querying, and that will involve the ability to page through results. With that interface defined and implemented we can start transition the rest of geoserver to it. That in my mind seems like the safest migration path.

-Justin

[1] http://www.mail-archive.com/geoserver-devel@lists.sourceforge.net/msg11127.html

On Tue, Oct 19, 2010 at 10:43 AM, Emanuele Tajariol <etj@anonymised.com> wrote:

Hi Justin,

that’s really nice, it looks like the changes we’ve been discussing a while
ago are taking their way into Geoserver :slight_smile:
As read in a previous email of yours, the interfaces are very close to the
ones I proposed. Andrea, I guess you may refer to some docs here:
JIRA: Catalog+DAO split:
http://jira.codehaus.org/browse/GEOS-3806
and here
R’n’D: Catalog+DAO refactoring:
http://geoserver.org/pages/viewpage.action?pageId=22708796

We may then want to extend such interfaces with paginated calls in order to
improve access in big catalogs. I know that such a change is not fully
backward compatible, but I wonder if it is in your plans.

Ciao,
Emanuele

Alle 17:45:19 di martedì 19 ottobre 2010, Andrea Aime ha scritto:

On Tue, Oct 19, 2010 at 3:54 PM, Justin Deoliveira <jdeolive@anonymised.com1501…>
wrote:

Hi all,
I am not sure if i made it clear when i posted the GSIP last week but i
would like to move it forward through voting. So far I have no votes on
this proposal from any PSC members.

Hey there… sorry for not replying, I did not do because I did not find
an easy to review the proposal, so I guessed I had to actually read the
patch line by line to figure it out.

I see the new interfaces (one is without javadoc comments btw) and I had
a quick look at the code but the structure of the changes escapes me when
just glancing at the code.
(btw, why is every access to the DAO synchronized inside the catalog,
would it be the same
to have the dao implementor synchronize every method if the dao is
not thread safe?)

I won’t have time to really look into the diffs until next weekend, I
guess having
a bit more of description would expedite the review (things like the
dao synch above for example).
You know, something that sits in the middle between “let’s have a DAO
approach” and actually going line by line through the patch.

But if you can wait till the weekend I can actually sit down head
clear and look into
it for good as is, without any change or extra description.

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



— Download new Adobe(R) Flash(R) Builder™ 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder™ 4 (formerly
Flex(R) Builder™) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Ing. Emanuele Tajariol

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Hello Justin, how is going? :slight_smile:

Sorry for the late response … I didn’t have the chance to deeply review the classes even because github seems to be down … anyway +1 on my side, introducing DAO pattern to GeoServer is a must imho.

Cheers,
Alessio.


Ing. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: (+39) 0584 96.23.13
fax: (+39) 0584 96.23.13
mobile:(+39) 349 82.27.000

http://www.geo-solutions.it
http://geo-solutions.blogspot.com
http://www.linkedin.com/in/alessiofabiani
http://twitter.com/simogeo

On Tue, Oct 19, 2010 at 7:16 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Thanks Emanuele, this comes out of the great work that you did so thank you :slight_smile:

About paging, yes it is in the plans. As I described in detail in an email to the developer list a few weeks go [1] this current patch is level 0. The very basics to get the hibernate catalog working in a way that does not totally disrupt the existing code base.

The next step is to modify the catalog interface to support a notion of querying, and that will involve the ability to page through results. With that interface defined and implemented we can start transition the rest of geoserver to it. That in my mind seems like the safest migration path.

-Justin

[1] http://www.mail-archive.com/geoserver-devel@anonymised.comforge.net/msg11127.html

On Tue, Oct 19, 2010 at 10:43 AM, Emanuele Tajariol <etj@anonymised.com> wrote:

Hi Justin,

that’s really nice, it looks like the changes we’ve been discussing a while
ago are taking their way into Geoserver :slight_smile:
As read in a previous email of yours, the interfaces are very close to the
ones I proposed. Andrea, I guess you may refer to some docs here:
JIRA: Catalog+DAO split:
http://jira.codehaus.org/browse/GEOS-3806
and here
R’n’D: Catalog+DAO refactoring:
http://geoserver.org/pages/viewpage.action?pageId=22708796

We may then want to extend such interfaces with paginated calls in order to
improve access in big catalogs. I know that such a change is not fully
backward compatible, but I wonder if it is in your plans.

Ciao,
Emanuele

Alle 17:45:19 di martedì 19 ottobre 2010, Andrea Aime ha scritto:

On Tue, Oct 19, 2010 at 3:54 PM, Justin Deoliveira <jdeolive@anonymised.com1501…>
wrote:

Hi all,
I am not sure if i made it clear when i posted the GSIP last week but i
would like to move it forward through voting. So far I have no votes on
this proposal from any PSC members.

Hey there… sorry for not replying, I did not do because I did not find
an easy to review the proposal, so I guessed I had to actually read the
patch line by line to figure it out.

I see the new interfaces (one is without javadoc comments btw) and I had
a quick look at the code but the structure of the changes escapes me when
just glancing at the code.
(btw, why is every access to the DAO synchronized inside the catalog,
would it be the same
to have the dao implementor synchronize every method if the dao is
not thread safe?)

I won’t have time to really look into the diffs until next weekend, I
guess having
a bit more of description would expedite the review (things like the
dao synch above for example).
You know, something that sits in the middle between “let’s have a DAO
approach” and actually going line by line through the patch.

But if you can wait till the weekend I can actually sit down head
clear and look into
it for good as is, without any change or extra description.

Cheers
Andrea


Ing. Andrea Aime
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



— Download new Adobe(R) Flash(R) Builder™ 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder™ 4 (formerly
Flex(R) Builder™) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Ing. Emanuele Tajariol

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Download new Adobe(R) Flash(R) Builder™ 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder™ 4 (formerly
Flex(R) Builder™) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

I tried to indicate my +1 last week. I am excited by the technical direction.
Jody

On Tue, Oct 19, 2010 at 11:54 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Hi all,
I am not sure if i made it clear when i posted the GSIP last week but i
would like to move it forward through voting. So far I have no votes on this
proposal from any PSC members.
Thanks.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

+0 (i havent had time to think about the approach, but support the concept),

On Thu, Oct 21, 2010 at 7:49 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I tried to indicate my +1 last week. I am excited by the technical direction.
Jody

On Tue, Oct 19, 2010 at 11:54 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Hi all,
I am not sure if i made it clear when i posted the GSIP last week but i
would like to move it forward through voting. So far I have no votes on this
proposal from any PSC members.
Thanks.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Thanks for voting folks. I have updated the proposal.

We have yet to officially hear from Simone, Mark, and Ben. Ben is on vacation so probably won’t hear from him. So i guess we can leave him 0 if we have enough positive votes from the others.

Andrea has said he would like to do an in depth review of the patch, possibly over the weekend? I have updated the patch in preparation, adding some javadocs to the CatalogDAO interface.

http://jira.codehaus.org/secure/attachment/51796/GEOS-3806.patch

-Justin

On Thu, Oct 21, 2010 at 9:07 PM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

+0 (i havent had time to think about the approach, but support the concept),

On Thu, Oct 21, 2010 at 7:49 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I tried to indicate my +1 last week. I am excited by the technical direction.
Jody

On Tue, Oct 19, 2010 at 11:54 PM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Hi all,
I am not sure if i made it clear when i posted the GSIP last week but i
would like to move it forward through voting. So far I have no votes on this
proposal from any PSC members.
Thanks.
-Justin

Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Download new Adobe(R) Flash(R) Builder™ 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder™ 4 (formerly
Flex(R) Builder™) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Ciao Justin,
I am generally +1 but there is a but for which I could be still -1
(don't get upset yet :wink: ).

The only thing that I do not like (and I did not like abut ETJ
implementation either) is that
we call a DAO what in reality should be a facade.
Let me explain, I personally prefer DAOs to be stupid simple and
expose CRUD operations
on a single class or hierarchy. Above that you can create a facade
that uses the various DAOs
adding some more logic that goes beyond what a single stupid simple
DAO can do ad take into account
higher level constraints. The thing is that at this point are already
into the business logic level and using the
postfix DAO is confusing for me.

I know this is subtle, but from my experience this can be a
life-savior whenever you have tricky problems
since layering things that way clearly separate pure data access code
from code that include business logic
about maintain the integrity of the ER model itself.

So, I would like to hear from you about these concerns, if you don't
have to address them, I don't want to be
a showstopper and I will go +0.

Ciao,
Simone.

-------------------------------------------------------

Notice that our office phone number has recently changed!
Please, update your records!

Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

-------------------------------------------------------

On Fri, Oct 22, 2010 at 5:59 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Thanks for voting folks. I have updated the proposal.
We have yet to officially hear from Simone, Mark, and Ben. Ben is on
vacation so probably won't hear from him. So i guess we can leave him 0 if
we have enough positive votes from the others.
Andrea has said he would like to do an in depth review of the patch,
possibly over the weekend? I have updated the patch in preparation, adding
some javadocs to the CatalogDAO interface.
http://jira.codehaus.org/secure/attachment/51796/GEOS-3806.patch
-Justin
On Thu, Oct 21, 2010 at 9:07 PM, Rob Atkinson <robatkinson101@anonymised.com>
wrote:

+0 (i havent had time to think about the approach, but support the
concept),

On Thu, Oct 21, 2010 at 7:49 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:
> I tried to indicate my +1 last week. I am excited by the technical
> direction.
> Jody
>
>
> On Tue, Oct 19, 2010 at 11:54 PM, Justin Deoliveira
> <jdeolive@anonymised.com> wrote:
>> Hi all,
>> I am not sure if i made it clear when i posted the GSIP last week but i
>> would like to move it forward through voting. So far I have no votes on
>> this
>> proposal from any PSC members.
>> Thanks.
>> -Justin
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>>
>> ------------------------------------------------------------------------------
>> Download new Adobe(R) Flash(R) Builder(TM) 4
>> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
>> Flex(R) Builder(TM)) enable the development of rich applications that
>> run
>> across multiple browsers and platforms. Download your free trials
>> today!
>> http://p.sf.net/sfu/adobe-dev2dev
>> _______________________________________________
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America
> contest
> Create new apps & games for the Nokia N8 for consumers in U.S. and
> Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Ciao Simone,

Thanks for the feedback. You are indeed correct in that what we are calling a dao is more of a facade. Apologies I am not so well versed when it comes to such terminology.

I would be fine with pushing for a more strict definition of dao in the design, and acutally break out a dao interface for each type of object, and rename currently what are calling a dao to a facade. While I agree this would be a better design it seems more of a semantic thing. And at this point I think we have bigger fish to fry, like modifying the apis to support querying with paging, etc… the basic scalability stuff, which was also a concern of yours :wink:

So, while I think this is worth while I would like to push this off to a future iteration of the work. However I would be fine with renaming CatalogDAO and GeoServerDAO to CatalogFacade and GeoServerFacade (or whatever name makes more sense) now.

I also don’t think this will be very problematic to add layer. Currently the Catalog and GeoServer interfaces are acting as facades for the dao/facades interfaces, so there api is shielded from the rest of the code base. And in the same way the dao/facade api would protect the catalog from multiple daos per type hierarchy when we decide to break them out.

2c.

So is renaming the interfaces enough to get your +1? Or should I mark you as +0?

-Justin

On Fri, Oct 22, 2010 at 10:47 AM, Simone Giannecchini <simone.giannecchini@anonymised.com> wrote:

Ciao Justin,
I am generally +1 but there is a but for which I could be still -1
(don’t get upset yet :wink: ).

The only thing that I do not like (and I did not like abut ETJ
implementation either) is that
we call a DAO what in reality should be a facade.
Let me explain, I personally prefer DAOs to be stupid simple and
expose CRUD operations
on a single class or hierarchy. Above that you can create a facade
that uses the various DAOs
adding some more logic that goes beyond what a single stupid simple
DAO can do ad take into account
higher level constraints. The thing is that at this point are already
into the business logic level and using the
postfix DAO is confusing for me.

I know this is subtle, but from my experience this can be a
life-savior whenever you have tricky problems
since layering things that way clearly separate pure data access code
from code that include business logic
about maintain the integrity of the ER model itself.

So, I would like to hear from you about these concerns, if you don’t
have to address them, I don’t want to be
a showstopper and I will go +0.

Ciao,
Simone.


===
Notice that our office phone number has recently changed!
Please, update your records!

Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313

mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/

http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo


On Fri, Oct 22, 2010 at 5:59 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Thanks for voting folks. I have updated the proposal.
We have yet to officially hear from Simone, Mark, and Ben. Ben is on
vacation so probably won’t hear from him. So i guess we can leave him 0 if
we have enough positive votes from the others.
Andrea has said he would like to do an in depth review of the patch,
possibly over the weekend? I have updated the patch in preparation, adding
some javadocs to the CatalogDAO interface.
http://jira.codehaus.org/secure/attachment/51796/GEOS-3806.patch
-Justin
On Thu, Oct 21, 2010 at 9:07 PM, Rob Atkinson <robatkinson101@anonymised.com>
wrote:

+0 (i havent had time to think about the approach, but support the
concept),

On Thu, Oct 21, 2010 at 7:49 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

I tried to indicate my +1 last week. I am excited by the technical
direction.
Jody

On Tue, Oct 19, 2010 at 11:54 PM, Justin Deoliveira
<jdeolive@anonymised.com.> wrote:

Hi all,
I am not sure if i made it clear when i posted the GSIP last week but i
would like to move it forward through voting. So far I have no votes on
this
proposal from any PSC members.
Thanks.
-Justin

Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Download new Adobe(R) Flash(R) Builder™ 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder™ 4 (formerly
Flex(R) Builder™) enable the development of rich applications that
run
across multiple browsers and platforms. Download your free trials
today!
http://p.sf.net/sfu/adobe-dev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Nokia and AT&T present the 2010 Calling All Innovators-North America
contest
Create new apps & games for the Nokia N8 for consumers in U.S. and
Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in
marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

renaming is enough to signal somehow the fact that sooner or later we
will factor out real DAO, at least IMHO.
Moreover it has the nice side effect to make my me and my ego happy
and feel like we were actually useful!

Simone.
-------------------------------------------------------

Notice that our office phone number has recently changed!
Please, update your records!

Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 05849623y 13
fax: +39 0584962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

-------------------------------------------------------

On Fri, Oct 22, 2010 at 6:58 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Ciao Simone,
Thanks for the feedback. You are indeed correct in that what we are calling
a dao is more of a facade. Apologies I am not so well versed when it comes
to such terminology.
I would be fine with pushing for a more strict definition of dao in the
design, and acutally break out a dao interface for each type of object, and
rename currently what are calling a dao to a facade. While I agree this
would be a better design it seems more of a semantic thing. And at this
point I think we have bigger fish to fry, like modifying the apis to support
querying with paging, etc... the basic scalability stuff, which was also a
concern of yours :wink:
So, while I think this is worth while I would like to push this off to a
future iteration of the work. However I would be fine with renaming
CatalogDAO and GeoServerDAO to CatalogFacade and GeoServerFacade (or
whatever name makes more sense) now.
I also don't think this will be very problematic to add layer. Currently the
Catalog and GeoServer interfaces are acting as facades for the dao/facades
interfaces, so there api is shielded from the rest of the code base. And in
the same way the dao/facade api would protect the catalog from multiple daos
per type hierarchy when we decide to break them out.

2c.
So is renaming the interfaces enough to get your +1? Or should I mark you as
+0?
-Justin
On Fri, Oct 22, 2010 at 10:47 AM, Simone Giannecchini
<simone.giannecchini@anonymised.com> wrote:

Ciao Justin,
I am generally +1 but there is a but for which I could be still -1
(don't get upset yet :wink: ).

The only thing that I do not like (and I did not like abut ETJ
implementation either) is that
we call a DAO what in reality should be a facade.
Let me explain, I personally prefer DAOs to be stupid simple and
expose CRUD operations
on a single class or hierarchy. Above that you can create a facade
that uses the various DAOs
adding some more logic that goes beyond what a single stupid simple
DAO can do ad take into account
higher level constraints. The thing is that at this point are already
into the business logic level and using the
postfix DAO is confusing for me.

I know this is subtle, but from my experience this can be a
life-savior whenever you have tricky problems
since layering things that way clearly separate pure data access code
from code that include business logic
about maintain the integrity of the ER model itself.

So, I would like to hear from you about these concerns, if you don't
have to address them, I don't want to be
a showstopper and I will go +0.

Ciao,
Simone.

-------------------------------------------------------

Notice that our office phone number has recently changed!
Please, update your records!

Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

-------------------------------------------------------

On Fri, Oct 22, 2010 at 5:59 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:
> Thanks for voting folks. I have updated the proposal.
> We have yet to officially hear from Simone, Mark, and Ben. Ben is on
> vacation so probably won't hear from him. So i guess we can leave him 0
> if
> we have enough positive votes from the others.
> Andrea has said he would like to do an in depth review of the patch,
> possibly over the weekend? I have updated the patch in preparation,
> adding
> some javadocs to the CatalogDAO interface.
> http://jira.codehaus.org/secure/attachment/51796/GEOS-3806.patch
> -Justin
> On Thu, Oct 21, 2010 at 9:07 PM, Rob Atkinson <robatkinson101@anonymised.com.>
> wrote:
>>
>> +0 (i havent had time to think about the approach, but support the
>> concept),
>>
>>
>>
>> On Thu, Oct 21, 2010 at 7:49 PM, Jody Garnett <jody.garnett@anonymised.com>
>> wrote:
>> > I tried to indicate my +1 last week. I am excited by the technical
>> > direction.
>> > Jody
>> >
>> >
>> > On Tue, Oct 19, 2010 at 11:54 PM, Justin Deoliveira
>> > <jdeolive@anonymised.com> wrote:
>> >> Hi all,
>> >> I am not sure if i made it clear when i posted the GSIP last week
>> >> but i
>> >> would like to move it forward through voting. So far I have no votes
>> >> on
>> >> this
>> >> proposal from any PSC members.
>> >> Thanks.
>> >> -Justin
>> >> --
>> >> Justin Deoliveira
>> >> OpenGeo - http://opengeo.org
>> >> Enterprise support for open source geospatial.
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Download new Adobe(R) Flash(R) Builder(TM) 4
>> >> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
>> >> Flex(R) Builder(TM)) enable the development of rich applications
>> >> that
>> >> run
>> >> across multiple browsers and platforms. Download your free trials
>> >> today!
>> >> http://p.sf.net/sfu/adobe-dev2dev
>> >> _______________________________________________
>> >> Geoserver-devel mailing list
>> >> Geoserver-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>> >>
>> >>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Nokia and AT&T present the 2010 Calling All Innovators-North America
>> > contest
>> > Create new apps & games for the Nokia N8 for consumers in U.S. and
>> > Canada
>> > $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
>> > marketing
>> > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi
>> > Store
>> > http://p.sf.net/sfu/nokia-dev2dev
>> > _______________________________________________
>> > Geoserver-devel mailing list
>> > Geoserver-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>> >
>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America
> contest
> Create new apps & games for the Nokia N8 for consumers in U.S. and
> Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Haha, done. Rename in progress :slight_smile:

On Fri, Oct 22, 2010 at 11:08 AM, Simone Giannecchini <simone.giannecchini@anonymised.com> wrote:

renaming is enough to signal somehow the fact that sooner or later we
will factor out real DAO, at least IMHO.
Moreover it has the nice side effect to make my me and my ego happy
and feel like we were actually useful!

Simone.

===
Notice that our office phone number has recently changed!
Please, update your records!

Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 05849623y 13

fax: +39 0584962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo


On Fri, Oct 22, 2010 at 6:58 PM, Justin Deoliveira <jdeolive@anonymised.com…> wrote:

Ciao Simone,
Thanks for the feedback. You are indeed correct in that what we are calling
a dao is more of a facade. Apologies I am not so well versed when it comes
to such terminology.
I would be fine with pushing for a more strict definition of dao in the
design, and acutally break out a dao interface for each type of object, and
rename currently what are calling a dao to a facade. While I agree this
would be a better design it seems more of a semantic thing. And at this
point I think we have bigger fish to fry, like modifying the apis to support
querying with paging, etc… the basic scalability stuff, which was also a
concern of yours :wink:
So, while I think this is worth while I would like to push this off to a
future iteration of the work. However I would be fine with renaming
CatalogDAO and GeoServerDAO to CatalogFacade and GeoServerFacade (or
whatever name makes more sense) now.
I also don’t think this will be very problematic to add layer. Currently the
Catalog and GeoServer interfaces are acting as facades for the dao/facades
interfaces, so there api is shielded from the rest of the code base. And in
the same way the dao/facade api would protect the catalog from multiple daos
per type hierarchy when we decide to break them out.

2c.
So is renaming the interfaces enough to get your +1? Or should I mark you as
+0?
-Justin
On Fri, Oct 22, 2010 at 10:47 AM, Simone Giannecchini
<simone.giannecchini@anonymised.com> wrote:

Ciao Justin,
I am generally +1 but there is a but for which I could be still -1
(don’t get upset yet :wink: ).

The only thing that I do not like (and I did not like abut ETJ
implementation either) is that
we call a DAO what in reality should be a facade.
Let me explain, I personally prefer DAOs to be stupid simple and
expose CRUD operations
on a single class or hierarchy. Above that you can create a facade
that uses the various DAOs
adding some more logic that goes beyond what a single stupid simple
DAO can do ad take into account
higher level constraints. The thing is that at this point are already
into the business logic level and using the
postfix DAO is confusing for me.

I know this is subtle, but from my experience this can be a
life-savior whenever you have tricky problems
since layering things that way clearly separate pure data access code
from code that include business logic
about maintain the integrity of the ER model itself.

So, I would like to hear from you about these concerns, if you don’t
have to address them, I don’t want to be
a showstopper and I will go +0.

Ciao,
Simone.


===
Notice that our office phone number has recently changed!
Please, update your records!

Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584962313
fax: +39 0584962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo


On Fri, Oct 22, 2010 at 5:59 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Thanks for voting folks. I have updated the proposal.
We have yet to officially hear from Simone, Mark, and Ben. Ben is on
vacation so probably won’t hear from him. So i guess we can leave him 0
if
we have enough positive votes from the others.
Andrea has said he would like to do an in depth review of the patch,
possibly over the weekend? I have updated the patch in preparation,
adding
some javadocs to the CatalogDAO interface.
http://jira.codehaus.org/secure/attachment/51796/GEOS-3806.patch
-Justin
On Thu, Oct 21, 2010 at 9:07 PM, Rob Atkinson <robatkinson101@anonymised.com>
wrote:

+0 (i havent had time to think about the approach, but support the
concept),

On Thu, Oct 21, 2010 at 7:49 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

I tried to indicate my +1 last week. I am excited by the technical
direction.
Jody

On Tue, Oct 19, 2010 at 11:54 PM, Justin Deoliveira
<jdeolive@…1501…> wrote:

Hi all,
I am not sure if i made it clear when i posted the GSIP last week
but i
would like to move it forward through voting. So far I have no votes
on
this
proposal from any PSC members.
Thanks.
-Justin

Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Download new Adobe(R) Flash(R) Builder™ 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder™ 4 (formerly
Flex(R) Builder™) enable the development of rich applications
that
run
across multiple browsers and platforms. Download your free trials
today!
http://p.sf.net/sfu/adobe-dev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Nokia and AT&T present the 2010 Calling All Innovators-North America
contest
Create new apps & games for the Nokia N8 for consumers in U.S. and
Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in
marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi
Store
http://p.sf.net/sfu/nokia-dev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Nokia and AT&T present the 2010 Calling All Innovators-North America
contest
Create new apps & games for the Nokia N8 for consumers in U.S. and
Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in
marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

On 23 October 2010 03:58, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Ciao Simone,
Thanks for the feedback. You are indeed correct in that what we are calling
a dao is more of a facade. Apologies I am not so well versed when it comes
to such terminology.
I would be fine with pushing for a more strict definition of dao in the
design, and acutally break out a dao interface for each type of object, and
rename currently what are calling a dao to a facade. While I agree this
would be a better design it seems more of a semantic thing. And at this
point I think we have bigger fish to fry, like modifying the apis to support
querying with paging, etc... the basic scalability stuff, which was also a
concern of yours :wink:
So, while I think this is worth while I would like to push this off to a
future iteration of the work. However I would be fine with renaming
CatalogDAO and GeoServerDAO to CatalogFacade and GeoServerFacade (or
whatever name makes more sense) now.
I also don't think this will be very problematic to add layer. Currently the
Catalog and GeoServer interfaces are acting as facades for the dao/facades
interfaces, so there api is shielded from the rest of the code base. And in
the same way the dao/facade api would protect the catalog from multiple daos
per type hierarchy when we decide to break them out.

2c.
So is renaming the interfaces enough to get your +1? Or should I mark you as
+0?
-Justin

Sorry for the pathetic response time on this one, I've been struggling
to get my mind around it. I do fully support the direction, so I'm a
+1.