[Geoserver-devel] Why is the importer rest api not using (fully) Xstream?

GeoServer GeoServer Developer
1

Hi,
looking at the importer rest code I’ve noticed there is custom, hand written
code that handles json parsing and encoding, along with some xstream
code… rather confusing in the end.

From what I can see, ImportJSONReader has quite a bit of hand written
code that can parse a json into a java object representing an import
session, and in some parts it uses xstream, others are hand-coded instead,
and the same goes for the write part.

What was the rationale to go there, why not simply use Xstream
for the whole code, and avoid the maintenance of hand written
parsing/encoding code?

This seems to make it unecessarily hard to add xml support to the REST
api, which is another quite evident inconsistency with the other REST api
in GeoServer.

Cheers
Andrea

···

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

2

The rationale for doing it this way was that while yes xstream is nice in that it allows you to not write any serialization/deserialization code out of the box it makes other things hard. Such as:

  • Customization, yes we have custom converters to make things look different but in the end you end up with more custom converter code then if you just broke out manual serialization code
  • You have less control over how your serialization format evolves, and it makes maintaining any type of rest api compatibility hard as your underlying objects change, sometimes this is good, sometimes not
  • Less control over what your objects look like and the structure of your json. Similar point to (1) but with the added emphasis that if your json is going to be consumed by a javascript client it matters. I’ve heard multiple complaints from folks writing applications (including myself) that the json produced by xstream is unnecessarily verbose and harder than necessary to navigate on the client side

Anyways, hopefully that provides some insight into why the decision was made. The idea was to try and use xstream for objects that we already had the converter infrastructure in place (ie. the catalog objects) and use manual serialization for the other objects, like imports, tasks, etc…

-Justin

···

On Thu, Feb 19, 2015 at 6:16 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
looking at the importer rest code I’ve noticed there is custom, hand written
code that handles json parsing and encoding, along with some xstream
code… rather confusing in the end.

From what I can see, ImportJSONReader has quite a bit of hand written
code that can parse a json into a java object representing an import
session, and in some parts it uses xstream, others are hand-coded instead,
and the same goes for the write part.

What was the rationale to go there, why not simply use Xstream
for the whole code, and avoid the maintenance of hand written
parsing/encoding code?

This seems to make it unecessarily hard to add xml support to the REST
api, which is another quite evident inconsistency with the other REST api
in GeoServer.

Cheers
Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

3

On Thu, Feb 19, 2015 at 3:58 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

The rationale for doing it this way was that while yes xstream is nice in
that it allows you to not write any serialization/deserialization code out
of the box it makes other things hard. Such as:

- Customization, yes we have custom converters to make things look
different but in the end you end up with more custom converter code then if
you just broke out manual serialization code
- You have less control over how your serialization format evolves, and it
makes maintaining any type of rest api compatibility hard as your
underlying objects change, sometimes this is good, sometimes not
- Less control over what your objects look like and the structure of your
json. Similar point to (1) but with the added emphasis that if your json is
going to be consumed by a javascript client it matters. I've heard multiple
complaints from folks writing applications (including myself) that the json
produced by xstream is unnecessarily verbose and harder than necessary to
navigate on the client side

Anyways, hopefully that provides some insight into why the decision was
made. The idea was to try and use xstream for objects that we already had
the converter infrastructure in place (ie. the catalog objects) and use
manual serialization for the other objects, like imports, tasks, etc...

Long story short, to support XML one has to build a DOM or something
similar and then perform a similar manual parse and encoding, right?

About objects already being encoded by catalog, it seems that layer is
manually handled too?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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

4

On Thu, Feb 19, 2015 at 8:05 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Thu, Feb 19, 2015 at 3:58 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

The rationale for doing it this way was that while yes xstream is nice in
that it allows you to not write any serialization/deserialization code out
of the box it makes other things hard. Such as:

- Customization, yes we have custom converters to make things look
different but in the end you end up with more custom converter code then if
you just broke out manual serialization code
- You have less control over how your serialization format evolves, and
it makes maintaining any type of rest api compatibility hard as your
underlying objects change, sometimes this is good, sometimes not
- Less control over what your objects look like and the structure of your
json. Similar point to (1) but with the added emphasis that if your json is
going to be consumed by a javascript client it matters. I've heard multiple
complaints from folks writing applications (including myself) that the json
produced by xstream is unnecessarily verbose and harder than necessary to
navigate on the client side

Anyways, hopefully that provides some insight into why the decision was
made. The idea was to try and use xstream for objects that we already had
the converter infrastructure in place (ie. the catalog objects) and use
manual serialization for the other objects, like imports, tasks, etc...

Long story short, to support XML one has to build a DOM or something
similar and then perform a similar manual parse and encoding, right?

Yeah, I guess so. Although if the api is to support both xml and json

making everything use xstream becomes more attractive despite all of the
above. Our initial rationale was that supporting json would be enough as I
don't see a lot of rest client developers that ask for xml when json is
available. If anything it's always the other way around.

About objects already being encoded by catalog, it seems that layer is

manually handled too?

Right, we broke out manual encoding for layer, I can't remember why exactly
(Ian might, as he was involved in that decision I think) but it more or
less boiled down to the above arguments I think.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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

5

On Thu, Feb 19, 2015 at 4:17 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Long story short, to support XML one has to build a DOM or something

similar and then perform a similar manual parse and encoding, right?

Yeah, I guess so. Although if the api is to support both xml and json

making everything use xstream becomes more attractive despite all of the
above. Our initial rationale was that supporting json would be enough as I
don't see a lot of rest client developers that ask for xml when json is
available. If anything it's always the other way around.

Server side software prefers to talk XML normally, and mass imports are not
something to be restricted to clients, on
the contrary, coupled with a cron-like engine they are the very source of
life of any system doing continous data
publishing (typical in metoc).

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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

6

On Thu, Feb 19, 2015 at 8:21 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Thu, Feb 19, 2015 at 4:17 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Long story short, to support XML one has to build a DOM or something

similar and then perform a similar manual parse and encoding, right?

Yeah, I guess so. Although if the api is to support both xml and json

making everything use xstream becomes more attractive despite all of the
above. Our initial rationale was that supporting json would be enough as I
don't see a lot of rest client developers that ask for xml when json is
available. If anything it's always the other way around.

Server side software prefers to talk XML normally, and mass imports are
not something to be restricted to clients, on
the contrary, coupled with a cron-like engine they are the very source of
life of any system doing continous data
publishing (typical in metoc).

Well json is pretty easy to handle on the server as well and I actually see
a lot of server software that uses json for configuration. I would
definitely say json parsing apis are much easier to use than xml, both dom
or sax. But perhaps you're referring to infrastructure that is already in
place that requires xml.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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

7

On Thu, Feb 19, 2015 at 8:21 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Thu, Feb 19, 2015 at 4:17 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Long story short, to support XML one has to build a DOM or something

similar and then perform a similar manual parse and encoding, right?

Yeah, I guess so. Although if the api is to support both xml and json

making everything use xstream becomes more attractive despite all of the
above. Our initial rationale was that supporting json would be enough as I
don't see a lot of rest client developers that ask for xml when json is
available. If anything it's always the other way around.

Server side software prefers to talk XML normally, and mass imports are
not something to be restricted to clients, on
the contrary, coupled with a cron-like engine they are the very source of
life of any system doing continous data
publishing (typical in metoc).

The assertion of 'software preferring to talk XML' is quite subjective at
best and an anthropomorphism at worse :slight_smile:

When software does become self-aware, my guess is it's 'preference' will be
to communicate in binary :stuck_out_tongue:

I believe when Justin mentioned 'rest client developers', he was referring
to 'API client' - as in, the consumer of the service. Indeed, the existing
importer API client is used server-side and is quite capable of being used
via cron without even knowing that JSON is used as the protocol.

Ian

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE

http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Ian Schneider
Software Engineer | Boundless <http://boundlessgeo.com>
ischneider@anonymised.com
1-877-673-6436
@boundlessgeo <http://twitter.com/boundlessgeo/&gt;

8

On Thu, Feb 19, 2015 at 4:37 PM, Ian Schneider <ischneider@anonymised.com>
wrote:

On Thu, Feb 19, 2015 at 8:21 AM, Andrea Aime <andrea.aime@anonymised.com
> wrote:

On Thu, Feb 19, 2015 at 4:17 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Long story short, to support XML one has to build a DOM or something

similar and then perform a similar manual parse and encoding, right?

Yeah, I guess so. Although if the api is to support both xml and json

making everything use xstream becomes more attractive despite all of the
above. Our initial rationale was that supporting json would be enough as I
don't see a lot of rest client developers that ask for xml when json is
available. If anything it's always the other way around.

Server side software prefers to talk XML normally, and mass imports are
not something to be restricted to clients, on
the contrary, coupled with a cron-like engine they are the very source of
life of any system doing continous data
publishing (typical in metoc).

The assertion of 'software preferring to talk XML' is quite subjective at
best and an anthropomorphism at worse :slight_smile:

When software does become self-aware, my guess is it's 'preference' will
be to communicate in binary :stuck_out_tongue:

I believe when Justin mentioned 'rest client developers', he was referring
to 'API client' - as in, the consumer of the service. Indeed, the existing
importer API client is used server-side and is quite capable of being used
via cron without even knowing that JSON is used as the protocol.

It is indeed a matter of preference. I live in a parallel universe where
XML is more popular among server side developers apparently

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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

9

Hi,
so to get practical, if I had to support XML, and made a pull request
that used xstream instead of hand conding, preserving the current json structure of course,
would it be accepted? If not, I’m open to suggestions… Should I start a new rest module
more aligned with the other GeoServer rest api?

In case it’s ok to modify the existing one, would I have to limit xstream usage to xml representation, or would it
make sense to also drop the current hand written json bindings?
From what I can tell xstream would produce the current json output with minimal customization, but I may
be wrong of course (please advise).

I may also need to provide full layer representation as opposed to the custom/limited
one currently supported by the json bindings, to allow userscontrol over the full layer configuration
(still discussing it, but the current minimum representation can really only address simple needs).

Cheers
Andrea

···

On Thu, Feb 19, 2015 at 4:39 PM, Andrea Aime <andrea.aime@anonymised.com…> wrote:

–

On Thu, Feb 19, 2015 at 4:37 PM, Ian Schneider <ischneider@anonymised.com> wrote:

It is indeed a matter of preference. I live in a parallel universe where XML is more popular among server side developers apparently

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

On Thu, Feb 19, 2015 at 8:21 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

The assertion of ‘software preferring to talk XML’ is quite subjective at best and an anthropomorphism at worse :slight_smile:

When software does become self-aware, my guess is it’s ‘preference’ will be to communicate in binary :stuck_out_tongue:

I believe when Justin mentioned ‘rest client developers’, he was referring to ‘API client’ - as in, the consumer of the service. Indeed, the existing importer API client is used server-side and is quite capable of being used via cron without even knowing that JSON is used as the protocol.

On Thu, Feb 19, 2015 at 4:17 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Server side software prefers to talk XML normally, and mass imports are not something to be restricted to clients, on
the contrary, coupled with a cron-like engine they are the very source of life of any system doing continous data
publishing (typical in metoc).

Yeah, I guess so. Although if the api is to support both xml and json making everything use xstream becomes more attractive despite all of the above. Our initial rationale was that supporting json would be enough as I don’t see a lot of rest client developers that ask for xml when json is available. If anything it’s always the other way around.

Long story short, to support XML one has to build a DOM or something similar and then perform a similar manual parse and encoding, right?

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

10

Practically I don’t think I am a position to block anything given that I am not very active at the moment, so I guess I would give a -0 vote. I still don’t really understand the need for XML over JSON, aside from a personal preference?

Going this direction will negatively impact the only known client (that I know of) for the importer [1], which I know is being used in production currently. What if the new xstream / xml based api could be developed alongside what’s already there? That would at least give people using the current api an out. And depending how the two evolve, deprecate one in the future.

$0.02

[1] https://github.com/boundlessgeo/gsimporter

···

On Fri, Feb 20, 2015 at 5:04 AM, Andrea Aime <andrea.aime@anonymised.com…> wrote:

Hi,
so to get practical, if I had to support XML, and made a pull request
that used xstream instead of hand conding, preserving the current json structure of course,
would it be accepted? If not, I’m open to suggestions… Should I start a new rest module
more aligned with the other GeoServer rest api?

In case it’s ok to modify the existing one, would I have to limit xstream usage to xml representation, or would it
make sense to also drop the current hand written json bindings?
From what I can tell xstream would produce the current json output with minimal customization, but I may
be wrong of course (please advise).

I may also need to provide full layer representation as opposed to the custom/limited
one currently supported by the json bindings, to allow userscontrol over the full layer configuration
(still discussing it, but the current minimum representation can really only address simple needs).

Cheers

Andrea

On Thu, Feb 19, 2015 at 4:39 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

On Thu, Feb 19, 2015 at 4:37 PM, Ian Schneider <ischneider@anonymised.com> wrote:

It is indeed a matter of preference. I live in a parallel universe where XML is more popular among server side developers apparently

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

On Thu, Feb 19, 2015 at 8:21 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

The assertion of ‘software preferring to talk XML’ is quite subjective at best and an anthropomorphism at worse :slight_smile:

When software does become self-aware, my guess is it’s ‘preference’ will be to communicate in binary :stuck_out_tongue:

I believe when Justin mentioned ‘rest client developers’, he was referring to ‘API client’ - as in, the consumer of the service. Indeed, the existing importer API client is used server-side and is quite capable of being used via cron without even knowing that JSON is used as the protocol.

On Thu, Feb 19, 2015 at 4:17 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Server side software prefers to talk XML normally, and mass imports are not something to be restricted to clients, on
the contrary, coupled with a cron-like engine they are the very source of life of any system doing continous data
publishing (typical in metoc).

Yeah, I guess so. Although if the api is to support both xml and json making everything use xstream becomes more attractive despite all of the above. Our initial rationale was that supporting json would be enough as I don’t see a lot of rest client developers that ask for xml when json is available. If anything it’s always the other way around.

Long story short, to support XML one has to build a DOM or something similar and then perform a similar manual parse and encoding, right?

11

On Fri, Feb 20, 2015 at 2:49 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Practically I don't think I am a position to block anything given that I
am not very active at the moment, so I guess I would give a -0 vote. I
still don't really understand the need for XML over JSON, aside from a
personal preference?

From the same token, why give people the possibility to use GML, zipped

shapefile, csv, kml... GeoJSON should be more than enough for everybody no?
And I'm not talking about some weird niche format, I'm talking about a
recognized industry standard, XML.....
GeoServer success is built on top of the ability to handle different data
sources, generate several different outputs, I don't understand the
reason for being this rigid on a single file format for the importer rest
api...

Going this direction will negatively impact the only known client (that I
know of) for the importer [1], which I know is being used in production
currently

But is it? If the patch maintains exactly the same output, how is the
existing client going to be negatively affected?
I did ask above about things that cannot be done via XStream aliases and
converers... do you see anything that will force me to break the existing
format? Of course I don't want that, the code change must be transparent to
outside users.

. What if the new xstream / xml based api could be developed alongside
what's already there? That would at least give people using the current api
an out. And depending how the two evolve, deprecate one in the future.

If it's impossible to match the existing output, yes of course. But if if's
technically feasible, is there any reason to keep the manual bindings
around?
Isn't it just going to be a maintenance overhead?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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

12

On Fri, Feb 20, 2015 at 7:04 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

On Fri, Feb 20, 2015 at 2:49 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

Practically I don't think I am a position to block anything given that I
am not very active at the moment, so I guess I would give a -0 vote. I
still don't really understand the need for XML over JSON, aside from a
personal preference?

From the same token, why give people the possibility to use GML, zipped
shapefile, csv, kml... GeoJSON should be more than enough for everybody no?
And I'm not talking about some weird niche format, I'm talking about a
recognized industry standard, XML.....
GeoServer success is built on top of the ability to handle different data
sources, generate several different outputs, I don't understand the
reason for being this rigid on a single file format for the importer rest
api...

You're losing me here as I think geoserver supporting formats to
ingest/encode spatial data in and the format used to represent entities in
a rest api are two pretty different things, but I am not really interested
in an argument with you based on opinion so I'll move on.

Going this direction will negatively impact the only known client (that I
know of) for the importer [1], which I know is being used in production
currently

But is it? If the patch maintains exactly the same output, how is the
existing client going to be negatively affected?
I did ask above about things that cannot be done via XStream aliases and
converers... do you see anything that will force me to break the existing
format? Of course I don't want that, the code change must be transparent to
outside users.

. What if the new xstream / xml based api could be developed alongside
what's already there? That would at least give people using the current api
an out. And depending how the two evolve, deprecate one in the future.

If it's impossible to match the existing output, yes of course. But if
if's technically feasible, is there any reason to keep the manual bindings
around?
Isn't it just going to be a maintenance overhead?

Sure, if the output can remain the same then that seems like a good

compromise to me.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

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

13

On Fri, Feb 20, 2015 at 5:04 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

Hi,
so to get practical, if I had to support XML, and made a pull request
that used xstream instead of hand conding, preserving the current json
structure of course,
would it be accepted? If not, I'm open to suggestions... Should I start a
new rest module
more aligned with the other GeoServer rest api?

Agree that if it did not break existing representations, it shouldn't be an
issue. Does seem like a bit of bike-shedding (as with Justin, I'll leave it
alone now).

In case it's ok to modify the existing one, would I have to limit xstream
usage to xml representation, or would it
make sense to also drop the current hand written json bindings?
From what I can tell xstream would produce the current json output with
minimal customization, but I may
be wrong of course (please advise).

I may also need to provide full layer representation as opposed to the
custom/limited
one currently supported by the json bindings, to allow userscontrol over
the full layer configuration
(still discussing it, but the current minimum representation can really
only address simple needs).

As for the layer representation, I personally would like to see this remain
light - the goal is to import data, not configure. Since the existing REST
API covers this, it also seems like a duplication of functionality/effort
(both on the service/API side, as well as the client).

Best,
Ian

--
Ian Schneider
Software Engineer | Boundless <http://boundlessgeo.com>
ischneider@anonymised.com
1-877-673-6436
@boundlessgeo <http://twitter.com/boundlessgeo/&gt;