[Geoserver-devel] Revamping GSIP-45

Hi all,

We'd like to revamp the GSIP-45
http://geoserver.org/display/GEOS/GSIP+45+-+Moving+GeoServer+model+in+a+standalone+module
Here's the related R'n'D page:
http://geoserver.org/display/GEOS/Resource+*Info+beans+refactoring

There have already been some discussion about it, and the proposed
implementation changed after some ideas from Justin:
http://www.mail-archive.com/geoserver-devel@lists.sourceforge.net/msg09231.html

This refactoring is quite important for better supporting integration with
external application. Please note that also the rest-client community module
had to reimplement its own model, mirroring the existing one.

   Ciao,
   Emanuele
--

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

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

phone: +39 0584962313
fax: +39 0584962313
mob: +39 3477895230

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

How does it relate to GSIP-52? http://geoserver.org/display/GEOS/GSIP+52±+Refactor+out+DAO+for+Catalog+and+Configuration

It might be easier to just make a new GSIP, that refers to 52, and proposes with regards to that, and addresses everything brought up in the gsip 45 email thread.

And what’s the timeframe you would do the work in? I was hoping we’d be moving to RC1 the first week of January, and this sounds like a potential major change that would push that back? Or did you want to target 2.2.x?

Justin’s on vacation, but I think it’s pretty important that he sound in. Hopefully he has some time to respond.

On Wed, Dec 22, 2010 at 10:35 AM, Emanuele Tajariol <etj@anonymised.com> wrote:

Hi all,

We’d like to revamp the GSIP-45
http://geoserver.org/display/GEOS/GSIP+45±+Moving+GeoServer+model+in+a+standalone+module
Here’s the related R’n’D page:
http://geoserver.org/display/GEOS/Resource+*Info+beans+refactoring

There have already been some discussion about it, and the proposed
implementation changed after some ideas from Justin:
http://www.mail-archive.com/geoserver-devel@lists.sourceforge.net/msg09231.html

This refactoring is quite important for better supporting integration with
external application. Please note that also the rest-client community module
had to reimplement its own model, mirroring the existing one.

Ciao,
Emanuele


Ing. Emanuele Tajariol

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

phone: +39 0584962313
fax: +39 0584962313
mob: +39 3477895230

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


Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl


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

I can’t quite remember where the idea left off but I remember coming to a good consensus. The highlights of which from memory are:

  • a pure refactoring with zero behavior changes
  • the new model model interfaces maintain and identical structure to the current ones except they are 1) prefixed with “I” and 2) all dependencies for “resource loading” are removed
  • the impl classes are factored out along with the interfaces
  • the existing interfaces implement the new ones and there should be any client code changes

Anything I am missing? With that the impact in terms of code base should be minimal. A new module called “api” (or something) and changes to the core config and catalog to implement the new interfaces and extend the new implementation classes.

-Justin

On Dec 22, 2010, at 12:25 PM, Chris Holmes <cholmes@anonymised.com> wrote:

How does it relate to GSIP-52? http://geoserver.org/display/GEOS/GSIP+52±+Refactor+out+DAO+for+Catalog+and+Configuration

It might be easier to just make a new GSIP, that refers to 52, and proposes with regards to that, and addresses everything brought up in the gsip 45 email thread.

And what’s the timeframe you would do the work in? I was hoping we’d be moving to RC1 the first week of January, and this sounds like a potential major change that would push that back? Or did you want to target 2.2.x?

Justin’s on vacation, but I think it’s pretty important that he sound in. Hopefully he has some time to respond.

On Wed, Dec 22, 2010 at 10:35 AM, Emanuele Tajariol <etj@anonymised.com> wrote:

Hi all,

We’d like to revamp the GSIP-45
http://geoserver.org/display/GEOS/GSIP+45±+Moving+GeoServer+model+in+a+standalone+module
Here’s the related R’n’D page:
http://geoserver.org/display/GEOS/Resource+*Info+beans+refactoring

There have already been some discussion about it, and the proposed
implementation changed after some ideas from Justin:
http://www.mail-archive.com/geoserver-devel@lists.sourceforge.net/msg09231.html

This refactoring is quite important for better supporting integration with
external application. Please note that also the rest-client community module
had to reimplement its own model, mirroring the existing one.

Ciao,
Emanuele


Ing. Emanuele Tajariol

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

phone: +39 0584962313
fax: +39 0584962313
mob: +39 3477895230

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


Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl


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

Ciao Chris,

as Justin has already pointed out, this will be a pure refactoring with zero
behavior changes, so I guess the description in the existing R'n'D and GSIP
pages should be enough.

We are planning to release these changes in 2.2.x , so the RC1 will not be
affected.

   Ciao,
   Emanuele

Alle 20:25:16 di mercoledì 22 dicembre 2010, Chris Holmes ha scritto:

How does it relate to GSIP-52?
http://geoserver.org/display/GEOS/GSIP+52+-+Refactor+out+DAO+for+Catalog+an
d+Configuration

It might be easier to just make a new GSIP, that refers to 52, and proposes
with regards to that, and addresses everything brought up in the gsip 45
email thread.

And what's the timeframe you would do the work in? I was hoping we'd be
moving to RC1 the first week of January, and this sounds like a potential
major change that would push that back? Or did you want to target 2.2.x?

Justin's on vacation, but I think it's pretty important that he sound in.
Hopefully he has some time to respond.

On Wed, Dec 22, 2010 at 10:35 AM, Emanuele Tajariol

<etj@anonymised.com>wrote:

> Hi all,
>
> We'd like to revamp the GSIP-45
>
> http://geoserver.org/display/GEOS/GSIP+45+-+Moving+GeoServer+model+in+a+s
>tandalone+module Here's the related R'n'D page:
> http://geoserver.org/display/GEOS/Resource+*Info+beans+refactoring
>
> There have already been some discussion about it, and the proposed
> implementation changed after some ideas from Justin:
>
> http://www.mail-archive.com/geoserver-devel@lists.sourceforge.net/msg0923
>1.html
>
> This refactoring is quite important for better supporting integration
> with external application. Please note that also the rest-client
> community module
> had to reimplement its own model, mirroring the existing one.
>
>
> Ciao,
> Emanuele
> --
>

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

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

phone: +39 0584962313
fax: +39 0584962313
mob: +39 3477895230

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

Ciao Justin,

the planned changes are exactly the ones you cited.

   Emanuele

Alle 22:52:43 di mercoledì 22 dicembre 2010, Justin Deoliveira ha scritto:

I can't quite remember where the idea left off but I remember coming to a
good consensus. The highlights of which from memory are:

* a pure refactoring with zero behavior changes
* the new model model interfaces maintain and identical structure to the
current ones except they are
  1) prefixed with "I" and
  2) all dependencies for "resource loading" are removed
* the impl classes are factored out along with the interfaces
* the existing interfaces implement the new ones and there should be any
client code changes

Anything I am missing? With that the impact in terms of code base should be
minimal. A new module called "api" (or something) and changes to the core
config and catalog to implement the new interfaces and extend the new
implementation classes.

-Justin

On Dec 22, 2010, at 12:25 PM, Chris Holmes <cholmes@anonymised.com> wrote:
> How does it relate to GSIP-52?
> http://geoserver.org/display/GEOS/GSIP+52+-+Refactor+out+DAO+for+Catalog+
>and+Configuration
>
> It might be easier to just make a new GSIP, that refers to 52, and
> proposes with regards to that, and addresses everything brought up in the
> gsip 45 email thread.
>
> And what's the timeframe you would do the work in? I was hoping we'd be
> moving to RC1 the first week of January, and this sounds like a potential
> major change that would push that back? Or did you want to target 2.2.x?
>
> Justin's on vacation, but I think it's pretty important that he sound in.
> Hopefully he has some time to respond.
>
> On Wed, Dec 22, 2010 at 10:35 AM, Emanuele Tajariol
> <etj@anonymised.com> wrote: Hi all,
>
> We'd like to revamp the GSIP-45
> http://geoserver.org/display/GEOS/GSIP+45+-+Moving+GeoServer+model+in+a+s
>tandalone+module Here's the related R'n'D page:
> http://geoserver.org/display/GEOS/Resource+*Info+beans+refactoring
>
> There have already been some discussion about it, and the proposed
> implementation changed after some ideas from Justin:
> http://www.mail-archive.com/geoserver-devel@lists.sourceforge.net/msg0923
>1.html
>
> This refactoring is quite important for better supporting integration
> with external application. Please note that also the rest-client
> community module had to reimplement its own model, mirroring the existing
> one.
>
>
> Ciao,
> Emanuele
> --
>
> -------------------------------------------------------
> Ing. Emanuele Tajariol
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584962313
> fax: +39 0584962313
> mob: +39 3477895230
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com
> -------------------------------------------------------
>
> -------------------------------------------------------------------------
>----- Learn how Oracle Real Application Clusters (RAC) One Node allows
> customers to consolidate database storage, standardize their database
> environment, and, should the need arise, upgrade to a full multi-node
> Oracle RAC database without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> 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
mob: +39 3477895230

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

Dear All,
just to clarify a little bit.
In principle the changes should be minimal as pointed out by justin, although I don’t think we will have enough time to do this within the timeframe of the 2.1, therefore I wold emanuele to shoot for the 2.2 and coordinate with justin on the db work.

Simone.

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, Dec 24, 2010 at 11:31 AM, Emanuele Tajariol <etj@anonymised.com1268…> wrote:

Ciao Chris,

as Justin has already pointed out, this will be a pure refactoring with zero
behavior changes, so I guess the description in the existing R’n’D and GSIP
pages should be enough.

We are planning to release these changes in 2.2.x , so the RC1 will not be
affected.

Ciao,
Emanuele

Alle 20:25:16 di mercoledì 22 dicembre 2010, Chris Holmes ha scritto:

How does it relate to GSIP-52?
http://geoserver.org/display/GEOS/GSIP+52±+Refactor+out+DAO+for+Catalog+an
d+Configuration

It might be easier to just make a new GSIP, that refers to 52, and proposes
with regards to that, and addresses everything brought up in the gsip 45
email thread.

And what’s the timeframe you would do the work in? I was hoping we’d be
moving to RC1 the first week of January, and this sounds like a potential
major change that would push that back? Or did you want to target 2.2.x?

Justin’s on vacation, but I think it’s pretty important that he sound in.
Hopefully he has some time to respond.

On Wed, Dec 22, 2010 at 10:35 AM, Emanuele Tajariol
<etj@anonymised.com>wrote:

Hi all,

We’d like to revamp the GSIP-45

http://geoserver.org/display/GEOS/GSIP+45±+Moving+GeoServer+model+in+a+s
tandalone+module Here’s the related R’n’D page:
http://geoserver.org/display/GEOS/Resource+*Info+beans+refactoring

There have already been some discussion about it, and the proposed
implementation changed after some ideas from Justin:

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

This refactoring is quite important for better supporting integration
with external application. Please note that also the rest-client
community module
had to reimplement its own model, mirroring the existing one.

Ciao,
Emanuele


Ing. Emanuele Tajariol

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

phone: +39 0584962313
fax: +39 0584962313
mob: +39 3477895230

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


Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl


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

Ah cool, 2.2.x sounds great.

C

On Fri, Dec 24, 2010 at 2:55 AM, Simone Giannecchini <simone.giannecchini@anonymised.com268…> wrote:

Dear All,
just to clarify a little bit.
In principle the changes should be minimal as pointed out by justin, although I don’t think we will have enough time to do this within the timeframe of the 2.1, therefore I wold emanuele to shoot for the 2.2 and coordinate with justin on the db work.

Simone.

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, Dec 24, 2010 at 11:31 AM, Emanuele Tajariol <etj@anonymised.com> wrote:

Ciao Chris,

as Justin has already pointed out, this will be a pure refactoring with zero
behavior changes, so I guess the description in the existing R’n’D and GSIP
pages should be enough.

We are planning to release these changes in 2.2.x , so the RC1 will not be
affected.

Ciao,
Emanuele

Alle 20:25:16 di mercoledì 22 dicembre 2010, Chris Holmes ha scritto:

How does it relate to GSIP-52?
http://geoserver.org/display/GEOS/GSIP+52±+Refactor+out+DAO+for+Catalog+an
d+Configuration

It might be easier to just make a new GSIP, that refers to 52, and proposes
with regards to that, and addresses everything brought up in the gsip 45
email thread.

And what’s the timeframe you would do the work in? I was hoping we’d be
moving to RC1 the first week of January, and this sounds like a potential
major change that would push that back? Or did you want to target 2.2.x?

Justin’s on vacation, but I think it’s pretty important that he sound in.
Hopefully he has some time to respond.

On Wed, Dec 22, 2010 at 10:35 AM, Emanuele Tajariol
<etj@anonymised.com>wrote:

Hi all,

We’d like to revamp the GSIP-45

http://geoserver.org/display/GEOS/GSIP+45±+Moving+GeoServer+model+in+a+s
tandalone+module Here’s the related R’n’D page:
http://geoserver.org/display/GEOS/Resource+*Info+beans+refactoring

There have already been some discussion about it, and the proposed
implementation changed after some ideas from Justin:

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

This refactoring is quite important for better supporting integration
with external application. Please note that also the rest-client
community module
had to reimplement its own model, mirroring the existing one.

Ciao,
Emanuele


Ing. Emanuele Tajariol

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

phone: +39 0584962313
fax: +39 0584962313
mob: +39 3477895230

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


Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl


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


Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl


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