Here are some thoughts.
* JSON
Sound fine to me to dump into main.
* GML output formats
INdeed this is a bit of a mess because they depend on the WFSConfiguration
objects in geoServer, rather than the ones in GeoTools. This is part of
clean up i have wanted to do for a while now. A preview of which is
available if you look at the class GML2OutputFormat2 (which isn't used) but
it shows how the output format can more or less be decoupled from geoserver
wfs for the actual encoding part. Unfortunately there is still a bit of
logic that the bindings in geoserver use to handle some corner cases that
the bindings in geotools do not.
SO i would prefer we move all the encoding logic back into geotools. I can
try to work toward in my "community time" but i will probably not be able
to get to that until next week.
* TransactionListener
Can you point to a diff of the changes? Or just summarize them. Sounds like
the changes are fine but i want to double check there is not negative
impact on the scripting modules
* RESTconfig
I am +1 on the idea of breaking apart the restconfig module. I would vote
to reorganized the rest modules into a tree like web and security, creating:
rest/
core/
config/
service/
On Thu, Mar 21, 2013 at 7:49 AM, Justin Deoliveira <[email protected]>wrote:
>
>
>
> On Thu, Mar 21, 2013 at 7:15 AM, Andrea Aime <[email protected]
> > wrote:
>
>> On Sun, Mar 17, 2013 at 6:25 PM, Andrea Aime
>> <[email protected]> wrote:
>> > If you are interested and want to help, here is what is left to be done:
>> > * review the patch
>> > * solve the GML3 issue.... do we really need to mimick the WFS output
>> that
>> > closely?
>> > Can we, for example, just encode GML3 using the GeoTools Encoder
>> without
>> > that many
>> > customizations?
>> > * consider splitting restconfig in two, one part that deals with the
>> > catalog, and that can build
>> > without being dragged down by WFS, and a restconfig-services, that
>> > contains only the
>> > service configuration portions, which will depend on WFS and the other
>> > services instead.
>>
>> A new weekend is incoming, I can move forward on this one, but I'd
>> need some feedback.
>> Nobody wants faster builds? :)
>>
>> I do, but have yet to have time to look into this and try to offer
> thoughts. I have time carved out for tomorrow to try and look at this and
> offer an opinion.
>
>> Cheers
>> Andrea
>>
>> --
>> ==
>> Our support, Your Success! Visit http://opensdi.geo-solutions.it 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
>>
>> -------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Geoserver-devel mailing list
>> [email protected]
>> 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.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
