Hi Justin, Gabriel,
once you have clarified GWC questions, even if I do not envisage particular
or blocking issues, you have my +1 on this GSIP.
If you plan to speak together on GWC please let us know what you decided.
Regards,
Alessio.
********************************************
Please take note that GeoSolutions
will be closed for Christmas holidays
from 27/12 to 30/12
********************************************
-------------------------------------------------------
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) 331 62.33.686
http://www.geo-solutions.it
http://geo-solutions.blogspot.com
http://www.linkedin.com/in/alessiofabiani
http://twitter.com/geosolutions_it
-------------------------------------------------------
On Wed, Dec 21, 2011 at 5:49 AM, Justin Deoliveira <[email protected]>wrote:
> Hey Gabriel,
>
> Good point. I haven't put much thought into that and to be honest have
> more or less done no testing with gwc.
>
> At first thought I think that it should "just work". Since gwc operates
> behind the ows dispatcher, the thread local should be set and so gwc should
> see the same workspace local view of the catalog and configuration that the
> ows services see. But for sure some testing is in order. Not sure what a
> great test plan would be... i guess a simple test would be to try a
> "cachable" wms request, but though a virtual service endpoint and for a
> layer that resides in a different workspace. The result should be an error
> that the layer does not exist.
>
> AS for gwc contributing its own ServiceInfo objects and having that play
> nice with the workspace local services stuff. Currently the way it is wired
> up is that the service gets listed on the workspace edit page if the
> service has an admin page. So that is why the gwc service objects don't
> show up currently.
>
> GWC follows a bit of a different pattern in than the typical services in
> that it aggregates a bunch of services (wmts, tms, etc...). The those
> ServiceInfo's are wired up now they wouldn't work with the workspace local
> services stuff. If they were first class citizens like the other
> ServiceInfo objects, that is persisted by GeoServerImpl, etc... then it
> would transparently work. And I guess adding individual ServiceAdminPage's
> for them.
>
> Anyways, something to talk through for sure. Perhaps we can do an IRC
> breakout.
>
>
> On Tue, Dec 20, 2011 at 8:55 PM, Gabriel Roldan <[email protected]>wrote:
>
>> Thanks for putting this up Justin, looks good at a first glance.
>>
>> I wonder though how all this affect GWC? like in does it work with the
>> integrated gwc out of the box (specially the virtual services work),
>> or what the gwc integration would need to consider to be called
>> virtual services + workspace local settings compatible?
>> Have you put any thought/testing onto that?
>> If not I'd like you to help me think about it. One thing that comes to
>> mind would be to make sure /<ws>/ows end points are respected by gwc.
>> Another would be for gwc to contribute its own ServiceInfo
>> implementations for its publishing services (tms, wmts, wmsc, etc), so
>> that they're catched up by the ws local settings page? anything else?
>>
>> TIA,
>> Gabriel
>>
>> On Tue, Dec 20, 2011 at 11:24 PM, Justin Deoliveira
>> <[email protected]> wrote:
>> > `Hi all,
>> >
>> > I put together a proposal for the workspace specific settings discussed
>> last
>> > week:
>> >
>> > http://geoserver.org/display/GEOS/GSIP+67+-+Workspace+Local+Settings
>> >
>> > Feedback much appreciated.
>> >
>> > -Justin
>> >
>> > --
>> > Justin Deoliveira
>> > OpenGeo - http://opengeo.org
>> > Enterprise support for open source geospatial.
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Write once. Port to many.
>> > Get the SDK and tools to simplify cross-platform app development. Create
>> > new or port existing apps to sell to consumers worldwide. Explore the
>> > Intel AppUpSM program developer opportunity.
>> appdeveloper.intel.com/join
>> > http://p.sf.net/sfu/intel-appdev
>> > _______________________________________________
>> > Geoserver-devel mailing list
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>> >
>>
>>
>>
>> --
>> Gabriel Roldan
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers.
>>
>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
