Thinking that through .... because of Java 11 package limitations they
gt-http would end up working in a new package:
package org.geotools.data.http;
interface HTTPClient {
...
}
And main would end up with some deprecations for a release cycle:
package org.geotools.data.ows;
/**
* @deprecated Please use org.geotools.data.http.HTTPClient
*/
interface HTTPClient extends org.geotools.data.http.HTTPClient {
...
}
That can work :)
--
Jody Garnett
On Tue, 5 Jan 2021 at 14:43, Roar Brænden <roar.brenden...@gmail.com> wrote:
> Hi,
>
> I've seen other mention not to use CommonFactoryFinder, and that would be
> easy to avoid. Moving the interfaces HTTPClient and HTTPResponse into
> gt-http means that all the classes in the namespace org.geotools.data.ows
> must be taken into gt-http. It seems easy to implement this.
>
> Initially I was thinking about moving all that only has to do with HTTP
> into the namespace org.geotools.http. It ended up being a too broad change.
> What do you all mean. Would it make sense to do such a refactoring?
>
> The classes I consider is:
>
> DelegateHTTPClient
> DelegateHTTPResponse
> HTTPClient
> HTTPResponse
> LoggingHTTPClient
> SimpleHttpClient
>
> Regards,
>
> Roar Brænden
>
> 5. jan. 2021 kl. 21:55 skrev Jody Garnett <jody.garn...@gmail.com>:
>
> Perfect, the proposal is starting to collect votes.
>
> I had one thing to discuss, use of CommonFactoryFinder? It would be great
> if use of this module can be independent of main, this would require
> its own own HTTPFactoryFinder or similar.
> --
> Jody Garnett
>
>
> On Mon, 4 Jan 2021 at 14:30, Roar Brænden <roar.brenden...@gmail.com>
> wrote:
>
>> Thanks,
>>
>> I think you've nailed the main goal by the proposal. I did some change to
>> the code example though.
>>
>> It would have been great to land this PR, and work with some of the bugs
>> regarding HTTPClient.
>>
>> Regards,
>>
>> Roar Brænden
>>
>>
>>
>> 4. jan. 2021 kl. 21:49 skrev Jody Garnett <jody.garn...@gmail.com>:
>>
>> I outlined the proposal here
>> https://github.com/geotools/geotools/wiki/HTTPClient-Factory
>>
>> I will ask for a review in tomorrow's meeting and trust we can get this
>> done ahead of the next release.
>> --
>> Jody Garnett
>>
>>
>> On Wed, 23 Dec 2020 at 16:15, Roar Brænden <roar.brenden...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I'm aware that you have a way of doing things, and that my approach
>>> wasn't in accordance with that. The history is that I worked with
>>> gt-tile-client this autumn and tried to make it work in parallel while
>>> fetching tiles. While looking at this I saw that all too many classes of
>>> Geotools take HTTPClient as an argument for the constructor, rather than
>>> using a factory pattern. And that's strange cause elsewhere you are using
>>> factory patterns a lot.
>>>
>>>
>>> > 23. des. 2020 kl. 23:46 skrev Jody Garnett <jody.garn...@gmail.com>:
>>> >
>>> > Roar:
>>> >
>>> > As you may have noticed in the meeting notes your HTTPClient ideas
>>> were discussed. As it has grown in the telling I agreed to write this up as
>>> a proposal for the community (it is how we do design documents and make
>>> sure everyone is in agreement on "big" or "impactful" changes.
>>> >
>>> > Before I get going what is your feeling between "gt-http" and "gt-web"?
>>> > --
>>>
>>>
>>> I would prefer to use http, as web is too wide.
>>> For the moment I have these two projects in the file structure:
>>>
>>> library / http (gt-http)
>>> plugin / http-commons (gt-http-commons)
>>>
>>>
>>> Regards
>>>
>>> Roar Brænden
>>
>>
>>
>
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
