On Fri, Jul 14, 2017 at 10:20 AM, Jody Garnett <[email protected]>
wrote:
> Torben could we do this without introducing additional "info" objects?
>
>
> Change it so that WebSeviceInfo contains has a "wstype" (similar to
> "dbtype") that is used to to configure WebServiceInfo with either
> WMSProtocolStratagy or WMTSProtcolStratagy responsible for speaking the
> correct protocol and producing a GridCoverage for the rendering engine.
>
> I think so. Looking at the current WMSLayer / WMSStore interface, it is
fairly general already. The only bit that actually depends on the service
type is this method in WMSStoreInfo:
/**
* Returns the underlying {@link WebMapServer}
* <p>
* This method does I/O and is potentially blocking. The
<tt>listener</tt> may be used to report
* the progress of loading the datastore and also to report any errors
or warnings that occur.
* </p>
*
* @param listener
* A progress listener, may be <code>null</code>.
*
* @return The datastore.
*
* @throws IOException
* Any I/O problems.
*/
WebMapServer getWebMapServer(ProgressListener listener) throws
IOException;
Where WebMapServer extends AbstractOpenWebService<WMSCapabilities, Layer>.
If one was to convert this to an abstract WebServiceInfo, then almost
everything would stay the same as in the current WMS__Info, just slightly
more general in the case of this one method.
On Fri, Jul 14, 2017 at 10:32 AM, Simone Giannecchini <
[email protected]> wrote:
> Hi Torben,
> while your suggestion makes sense and I have asked Emanuele to take into
> account I am also a bit reluctant to follow it.
>
> We tried to stick to the current structure (not saying it is good or bad,
> it is just the way it is) and doing a general refactor now might give us
> more harm than anything
> as it would introduce instability and open a can of worms.
>
> My main concern is that adding a new Resource interface has a greater
potential to introduce instability then extending / refactoring an existing
one, and in ways that may be less immediately apparent.
> So let's see what Emanuele says but I would more in favour of refactoring
> the whole thing separately, even because winter is coming (see other email
> threads).
>
> I would think that picking an approach and sticking with it is less
disruptive overall, as well as taking less effort, but I do understand that
things are busy for everyone with the upcoming code freeze and everything
else.
I would certainly be interested in hearing your thoughts Emanuele.
Torben
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
