Already taken :) Or are you implying that all the settings just get rolled
into the workspace interface?
On Wed, Dec 14, 2011 at 11:37 PM, David Winslow <dwins...@opengeo.org>wrote:
> How about:
>
> "WorkspaceInfo"
>
> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
> On Wed, Dec 14, 2011 at 6:19 PM, Justin Deoliveira
> <jdeol...@opengeo.org>wrote:
>
>> Thanks Andrea, I think this way is much cleaner as well. And we can
>> minimize api impact by keeping all the methods on GeoServerInfo intact (but
>> deprecated) for now.
>>
>> Question about names. What should the new interface be called?
>>
>> SettingsInfo
>> LocalSettingsInfo
>> ServiceSettingsInfo
>> WWWSettingsInfo
>>
>> Candidates welcome. Thanks.
>>
>> -Justin
>>
>> On Wed, Dec 14, 2011 at 1:23 PM, Andrea Aime <
>> andrea.a...@geo-solutions.it> wrote:
>>
>>> On Mon, Dec 12, 2011 at 7:08 PM, Justin Deoliveira <jdeol...@opengeo.org
>>> > wrote:
>>>
>>>> Hi all,
>>>>
>>>> The subject is kind of an oxymoron but I am tasked with continuing on
>>>> some of the workspace local / virtual service configuration work. The last
>>>> chunk of work made it possible to configure services separately per
>>>> workspace. The next chunk involves making the global config configurable
>>>> per workspace.
>>>>
>>>> Now, one has to ask the question if this makes sense at all, since many
>>>> of the options are indeed global, and would not / could not be configured
>>>> local to a workspace. For instance, the jai settings. But some settings
>>>> might be configurable per workspace, like contact info, verbose exception
>>>> reporting, etc... so i wanted to start some discussion to try and get an
>>>> idea on how to proceed.
>>>>
>>>> The first possibility would be to refactor the GeoServerInfo class into
>>>> two parts, those settings that could be workspace specific, and those that
>>>> could not. I haven't thought too much about how this would look but it wold
>>>> be a significant change to the catalog api, meaning lots of updating of
>>>> client code.
>>>>
>>>> The second possibility is to follow the same sneaky approach we use for
>>>> the services and that is return a different GeoServerInfo object based on
>>>> the local workspace thread local in play. The issue I see here is again the
>>>> settings that are truly global. A possible approach here could be to wrap
>>>> the workspace local GeoServerInfo objects in a proxy or wrapper that makes
>>>> certain fields read only, or perhaps hides them all together. In the UI we
>>>> could hid those fields all together.
>>>>
>>>> Thoughts/opinions?
>>>>
>>>
>>> I'd go for the split between what's really global (jai, logs) and what
>>> it makes
>>> sense to configure once per workspace (point of contact and the like).
>>> I understand and agree it's going to take API changes, but it also sets
>>> a clear
>>> path forward for the future.
>>> Javadocs should explain clearly who does what so that when adding a new
>>> "global" option one can choose wheter to make it "per worskpace global"
>>> or "universally global"
>>>
>>> My 2 cents :)
>>>
>>> Cheers
>>> Andrea
>>>
>>>
>>> --
>>> -------------------------------------------------------
>>> Ing. Andrea Aime
>>> GeoSolutions S.A.S.
>>> Tech lead
>>>
>>> Via Poggio alle Viti 1187
>>> 55054 Massarosa (LU)
>>> Italy
>>>
>>> phone: +39 0584 962313
>>> fax: +39 0584 962313
>>> mob: +39 339 8844549
>>>
>>> http://www.geo-solutions.it
>>> http://geo-solutions.blogspot.com/
>>> http://www.youtube.com/user/GeoSolutionsIT
>>> http://www.linkedin.com/in/andreaaime
>>> http://twitter.com/geowolf
>>>
>>> -------------------------------------------------------
>>>
>>>
>>
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Cloud Computing - Latest Buzzword or a Glimpse of the Future?
>> This paper surveys cloud computing today: What are the benefits?
>> Why are businesses embracing it? What are its payoffs and pitfalls?
>> http://www.accelacomm.com/jaw/sdnl/114/51425149/
>> _______________________________________________
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
http://www.accelacomm.com/jaw/sdnl/114/51507609/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
