Gabriel I am concerned by both the "clean up cruft" line in your origional
plan; and your commends about FilterFactory and issues with namespace in
this email.
It sounds like you recognize the breath of scope you are talking about it
beyond the requirements of this current proposal. This proposal c
chiming in (late)
Afaik these are some of the most important things to address geoserver wise:
- Catalog (already discussed and quite
- FilterFactory: it is namespace aware or its unuseful. The approach taken in
the app-schema modules is the one I like. I.e. PropertyName is given a ns
context (N
Jody Garnett wrote:
> I guess I will wait for patches to make my final judgment and vote
> for or against the proposal, but this seems to be happening a bit
> opaquely.
>
>
> I am not sure that approach works Justin - need a clear GSIP before
> starting work do we not?
The proposal l
:44 PM
To: Caradoc-Davies, Ben (E&M, Kensington)
Cc: Andrea Aime; Woodcock, Robert (E&M, Kensington); Fraser, Ryan (E&M,
Kensington); Geoserver-devel; Geotools-Devel list; Atkinson, Rob (CLW, Lucas
Heights)
Subject: Re: [Geoserver-devel] GSIP 31 - Use Data Access API
Sorry to chime i
Chris Holmes wrote:
> So my main problem with this paragraph is the notion that the DataAccess
> API is 'well supported' in GeoTools. Has it seen any real use in
> production? Has it been integrated in stable versions of any projects?
No, nor will it, until it is supported by GeoServer. Chicke
Sorry to chime in even later. A few thoughts
Ben Caradoc-Davies wrote:
> Andrea Aime wrote:
>> Ben Caradoc-Davies ha scritto:
>>> I have renamed the DataAccess proposal and now propose it as GSIP 31.
>>> http://geoserver.org/display/GEOS/GSIP+31+-+Use+DataAccess+API
>> The general idea in the GSI
> Hmmm... I don't think the inside-out approach was the cause of the
> problem. This is just my opinion but the lack of funding and failure to
> engage the core developer community is what led to these forks not going
> anywhere.
Sounds like its worth being aware that in the last round of effort
t
Justin Deoliveira wrote:
> I will be honest with you, I am skeptical of your time line given the
> current state of the proposal and the fact that you are more or less
> proposing a "wait and see" for an estimate of the work.
Scepticism is a good thing!
Estimation is hard, doubly so when I am t
Justin Deoliveira wrote:
>> Is a freeze in effect on trunk? I was unaware of this. We can hold off
>> if you are wanting to branch in the next few days.
> In the next few days no. But in the next few months yes. Since your
> proposal does not have any time lines attached to it, and is not on the
>
> The timeline for the first API changes is 30 Jan (two weeks from today).
> It is mostly done and will likely take a few more days, double and round
> up for troubleshooting and overheads.
>
> We will get a better idea of how much work remains when we run
> community/app-schema/sample-data
>
> Is a freeze in effect on trunk? I was unaware of this. We can hold off
> if you are wanting to branch in the next few days.
In the next few days no. But in the next few months yes. Since your
proposal does not have any time lines attached to it, and is not on the
road map with any time atta
Justin Deoliveira wrote:
> Sorry to chime in late. To add to Andrea's feedback, not only is
> resourcing important for this one, but also is the time. Since the
> changes are quite extensive in GeoServer they must be done in a way that
> does not disrupt the entire project.
Of course.
> At th
Sorry to chime in late. To add to Andrea's feedback, not only is
resourcing important for this one, but also is the time. Since the
changes are quite extensive in GeoServer they must be done in a way that
does not disrupt the entire project. At the same time doing this on a
branch has proven ti
Andrea Aime wrote:
> Ben Caradoc-Davies ha scritto:
>> I have renamed the DataAccess proposal and now propose it as GSIP 31.
>> http://geoserver.org/display/GEOS/GSIP+31+-+Use+DataAccess+API
>
> The general idea in the GSIP is fine, but it's a very, very big
> topic that requires changes in both G
Ben Caradoc-Davies ha scritto:
> Jody,
>
> I have renamed the DataAccess proposal and now propose it as GSIP 31.
> http://geoserver.org/display/GEOS/GSIP+31+-+Use+DataAccess+API
>
> Note that the proposal is not specific to app-schema. It proposes
> support for all DataAccess implementations.
Th
Jody,
I have renamed the DataAccess proposal and now propose it as GSIP 31.
http://geoserver.org/display/GEOS/GSIP+31+-+Use+DataAccess+API
Note that the proposal is not specific to app-schema. It proposes
support for all DataAccess implementations.
I have also created a container Jira issue:
htt
16 matches
Mail list logo
