The REST API exposes metadata attributes in both JSON and XML formats, so
it could be argued that either format is equally convenient. I think the
big problem is documentation though - without digging into GeoServer's code
is it possible to figure out what keys to use and what the values should
look like?
When I work with the REST API I often find myself making a configuration
through the web UI so I can get a "template" object. This is ok as far as
it goes, but I'm never confident I know about the acceptable range of
values for a setting, etc. That goes double when the value is some
complicated object instead of a simple string.
Just throwing it out there.
--
David Winslow
OpenGeo - http://opengeo.org/
On Wed, Jan 25, 2012 at 11:54 AM, Gabriel Roldan <grol...@opengeo.org>wrote:
> Hey Andrea, thanks for the great feedback.
> comments inline.
>
> On Wed, Jan 25, 2012 at 10:33 AM, Andrea Aime
> <andrea.a...@geo-solutions.it> wrote:
> > On Tue, Jan 24, 2012 at 6:32 PM, Gabriel Roldan <grol...@opengeo.org>
> wrote:
> >>
> >> Hello all,
> >>
> >> I'd like to ask for your opinions on a number of GWC integration
> >> improvements, as a continuation of the earlier work presented a couple
> >> weeks ago, for which I'm copying the screenshots bellow.
> >
> >
> > They look good (most of them at least)
> >
> >>
> >> These are the final bits for the long standing work described at
> >> http://jira.codehaus.org/browse/GEOS-4460
> >>
> >> The goal is to make the integrated gwc configuration much easier,
> >> allowing to configure both gridsets and cached layers through the UI.
> >>
> >> But besides what can be inferred from the screenshots, I wanted to
> >> gather some feedback on the following issues:
> >> - When we stopped faking a gwc's WMSLayer per GeoServer layer/group,
> >> we started storing the geoserver's tile layer configuration options in
> >> each Layer(Group)Info's metadata map, as a set of properties
> >> (GWC.enabled, GWC.gutter, GWC.gridsets, etc). Now, while enabling to
> >> configure almost every aspect of the cached layer, instead of storing
> >> a single metadata entry for each cached layer property, I'd rather
> >> store the whole tile layer configuration as a single metadata entry,
> >> in its JSON representation. Earlier experience in doing that is the
> >> storage of AuthorityURLInfo as a JSON entry in the LayerInfo and
> >> LayerGroupInfo metadata map, and it seems to be working well. So if
> >> there's no opposition I'd store the tile layer configuration as a
> >> single JSON entry in the metadata map, allowing for the natural
> >> evolution of the cached layer configuration without extra bloating of
> >> the metadata map (backwards compatible with the current set of
> >> entries, of course).
> >
> >
> > Works for me. Wondering, why JSON and not XML?
> > If you look at SQL views setups they are stored as xml instead, making
> > it look more "natural" if you look at the xml file (which you will see
> when
> > using rest config) and won't require mixing technologies when building
> > rest requests.
> Actually, I'll look into how SQL views are stored. I agree XML would
> fit more naturally. Thanks for the tip.
>
> >>
> >> - The other things I'd like to gather feedback about are related to the
> >> UI.
> >> * To start with, I got some feedback on that the "Cached Layers" menu
> >> entry on the "Data" menu is kind of awkward/confusing. As background
> >> information, the only reason for that page to exist instead of being
> >> integrated directly with the regular "Layers" page is that GWC
> >> supports also externally configured tile layers, which wouldn't fit on
> >> the layers/layergroup pages. So the proposal is to get rid of that
> >> menu entry, and instead integrate the list of cached layers (both
> >> geoserver's and external) as a tab in the "GeoWebCache" configuration
> >> page.
> >
> >
> > Works for me. Wondering if the GWC page could get too busy though...
> > another option could be to have a Tile Cache group in the side menu
> > and have the tabs be menu entries there. At the same time screens are
> > getting larger but not taller, I guess we're running out of vertical
> space
> > eh?
> Works for me that way too. Thinking of how such a menu would look like:
> - Tile Cache
> -- Global Settings --> <http://skitch.com/groldan/sets/gqn/gwc-ui>
> -- Tile Matrix Sets --> GridSets list with access to configuration.
> Called TileMatrixSet instead cause it comes from an actual spec rather
> than being GWC specific?
> -- Cached Layers --> list of cached layers (quota usage, common
> operations like seed/truncate)
>
> Besides, at some point the gwc offered services (wms-c, tms, wmts,
> etc) should have its own entry besides wms/wcs/wfs. But for the time
> being it'd be overwhelming as gwc is not really designed with that
> sort of (basic) configurability.
> >
> >>
> >>
> >> * Rename the "GeoWebCache" menu entry in the settings menu. Looks like
> >> people need to know what "GeoWebCache" is. It'd be better to call that
> >> menu entry something more related to what it does, like "Tile Cache"
> >> or something like that. Suggestions welcomed.
> >
> >
> > Tile Cache sounds fine
>
> k, guess I'll stick to it.
>
> >
> >>
> >>
> >> * Make the LayerGroup edit page tabbed. It's getting messy
> >> <http://skitch.com/groldan/g1s3j/11-tilelayer-config-for-layergroup>.
> >> It'd be better if it had tabs just like the Layer/Resource edit page,
> >> so that tile caching has it's own tab:
> >> <http://skitch.com/groldan/g1s3r/10-tilelayer-config-for-layerinfo>
> >
> >
> > Yep
> >
> > This looks like a very large amount of changes. Is it going to land on
> > trunk only? Eventually for some time, so that we can kick its tires
> > before backporting on 2.1.x?
>
> _trunk only_, plus a strong desire to get a stable branch out of 2.2.x
> sooner rather than later. Although I'm not sure for how long we plan
> to keep 2.1.x as _the_ stable branch, it looks to me like 2.2.x is in
> need to get some real work testing so we should start releasing betas
> out of it.
>
> > That said, some of the things we did only on trunk like rendering
> > transformations and time/elevation support with an intention of
> > backporting later actually never came back, there is an objective
> > difficulty in doing a backport one/two months later when the code
> > has had the time to move.
>
> I'll probably maintain a 2.1.x integration branch on git. First,
> because I want this to get tested on trunk and get as many bug fixes
> as possible before even thinking of backporting to 2.1.x. But, _if_ we
> found out it deserves to be on the 2.1.x branch, the port shouldn't be
> that hard because both 2.2.x and 2.1.x and based on the same gwc
> version. There are a couple things that the 2.2.x version has that the
> 2.1.x backport won't though: integration with TIME/ELEVATION
> configuration for example. Can't remember if something else.
>
> Cheers,
> Gabriel
>
> >
> > 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
> >
> > -------------------------------------------------------
>
>
>
> --
> Gabriel Roldan
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
