Yes my plan was ultimately to hide the Workspace parameter and have the
filter added and updated automatically the way the style filter is so it
would all be transparent to the user. I don't think you're missing
anything, I just wanted to make sure workspace renames were covered.
On 2 February 2015 at 12:44, Andrea Aime <[email protected]>
wrote:
> On Mon, Feb 2, 2015 at 8:31 PM, Kevin Smith <[email protected]>
> wrote:
>
>> I was looking at the same two problems in a different way. I'd
>> considered the prefix route on styles but hadn't noticed that solution to
>> the LayerGroups issue and wanted to solve both. So I ended up working on
>> improving the workspace parameter filter option instead, which lead to some
>> improvements in GWC I'm still working on, specifically GWC ticket #170.
>> The work I did should still be able to simplify the Style filter and make
>> it more robust, while also making other new parameter filters with
>> similarly dynamic behaviour easier to write and generally helping to avoid
>> 'leaking' of parameterized tile caches, particular when using the RexExp
>> filter.
>>
>> I don't think my route would have been backportable, and would have been
>> a stretch to make it into GWC 1.7.x/GS 2.7.x now that we are beta so, even
>> though it sort of obsoletes what I've been working on for the past few
>> days, I'm glad to see this.
>>
>
> I did not try to make the work backportable either (not with that
> intention at least), but I find the workspace parameter... ugh....
> GWC integration must be transparent, it's the primary feature of the
> integrated GW, a solution that breaks it is imho no solution, but a
> temporary band-aid in
> user's face (e.g., exactly where it should not be, band aids are ugly, but
> if needs be, better hide them under the carpet).
>
Yes my plan was ultimately to hide the Workspace parameter and have the
filter added and updated automatically the way the style filter is so it
would all be transparent to the user. The backportability issues I had
with my solution were that it involved API changes in GWC:
BlobStoreListener ended up with a new event to handle parameterizations
being purged. I wasn't happy with either of trying to put it in 1.7 this
late or waiting for 1.8. Since your solution is much less intrusive and
confined to GS, it should be able to make GS 2.7 and my parameterization
purge/dynamic param filter work can go into GWC 1.8.
>
> I see your comments about moving the workspace, did not consider it in
> fact (2.5 hours hack on a Sunday morning... that's why I asked for a review
> :-p ),
> but I don't see a problem taking it into account in a similar way to how
> we consider workspace name changes in layers... am I missing something?
>
I just wanted to make sure that case was covered but I don't think it
presents any particular issues to your approach. It was one of the rare
but annoying special cases that made my approach complicated.
--
Kevin Smith
Software Engineer | Boundless <http://boundlessgeo.com/>
[email protected]
+1-778-785-7459
@boundlessgeo <http://twitter.com/boundlessgeo/>
<http://twitter.com/boundlessgeo/>
[image: http://boundlessgeo.com/]
<http://boundlessgeo.com/>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
