Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi all,
I have been thinking about virtual configurations and resource
publishing split at the data structure level. Up until we have MapInfo:
MapInfo {
String getName();
List<LayerInfo> getLayers();
List<StyleInfo> getStyles();
List<String> getSRSs();
...
}
Not sure about styles and srs... SRS are part of the WMS configuration,
and styles WMS wise are simply not something that stands up on its own.
I guess by that you're trying to limit the styles that one can see
by doing direct access to them in styles=...?
Hmmm... sure you it only applies to WMS. As of WFS 1.1 SRS's are into the mix for WFS as well as the capabilities document advertises which SRS's apply to a feature type.
I can see the argument for styles however. That said we have modeled styles as a first level construct in the catalog, so I was more or less continuing on that path. But yeah, including styles is not really a strong case... ok with leaving it out.
Which gives us basically the data side of the equation, but not the
services. One of the things undoubtedly people will want to do with a
virtual configuration is limit the services that can access a map. Now
we could do this:
MapInfo {
List<ServiceInfo> getServices()
}
But this kind of seems off. Mainly because "map" lives on the catalog side of the fence, and services are a "configuration" entity. So the thought occurred to me to come up with another interface. For lack of a better name I am calling it a "profile". It would look something like:
ProfileInfo {
String getName();
List<Map> getMaps();
List<ServiceInfo> getServices();
}
I think it would also make sense if we want to start attaching other bits of "virtual configuration". I am thinking things here like logging, contact info, etc....
So profile complement maps by sitting on the service side of the fence?
Observations:
- not sure why we'd want multiple maps per profile. 1-1 relantionship
would seem more natural to me
Yeah I thought about this too. I guess my rationale was that multiple maps would be more flexible. To illustrate my train of thought I am considering a "production" profile and a "development" profile. The production one would want to be tweaked out, production logging, etc.. etc.. and maybe the development one not. Within those profiles you may wish to have multiple maps, maybe one for publishing vector data, and another for publishing WMS...
Anyways, it would be a shear convenience as the only real purpose it would serve would be to create some configurations that could be shared and to perhaps prevent some duplication.
I would be all for at this point keeping things simple and leaving the relationship as 1-1.
- actually a profile should be able to override most of the
services, so it seems a good idea to have service overrides,
looks better than having a list of srs in the MapInfo.
- what about always having a profile around, and name one the "default"
just like we said we would have had a default map? This might reduce
the number of special case handling in the code (e.g., no services
lingering in the void without being attached to a profile, same
goes for the "default" map).
Sounds like a good idea to me.
Wondering how the overrides would play thought? Say you have a basic
WFS setup. And that for a profile you want to override it.
So, is the override working on an attribute by attribute basis?
Or you copy over the default wfs service info and from there on
the two live separate lives?
The latter seems to be easier to configure to me.
Yes, the latter was what I had in mind as well.
How would profiles be shown in the UI? They end up influencing
what you get when you click on a service configuration, but
also the layer list (stores and workspaces would be unaffected,
maybe styles too?).
It seems that this has to be done in some global, prominent setting,
a context of sort. Could be just a drop down at the top of
the left menu allowing you to choose the "active" profile (the one
being edited).
Good point. Not sure what the best way about going about this is. The drop down for active profile seems nice as it does not require us to deal with nesting, ie a top level profiles and then drill down into services, etc...
I am however curious to hear what the designers think about this one.
Another thing that's bugging me is that there is a list of things
that do pertain to configuration that are still left out,
think security, srs handling. They would need to be part of
the profile as well, and imho, participate as first level
elements in the config of GeoServer. So far they have been left
out because it was easier to code them up as properties files
when they were introduced, but they should come back so that we
have something we can call a "config", now what we have is kind
of a set of unrelated pieces.
+1. We need to come up with interfaces in our model for these guys.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
