[Geoserver-devel] Planning

[Chris_Holmes1]

So at TOPP we're taking a bit of a hiatus from paid work to focus on
some core improvements on GeoServer which should hopefully make future
development even faster. We've focused a lot on user facing features in
the past couple years, neglecting some core annoyances.

Chief among those is the core configuration classes and the outdated
struts (1) user interface technology. I believe Justin has been making
progress on the configuration stuff, and it should hopefully get on to
trunk soon. The UI evaluation needs to be fired up again, and I'm
hoping we can select a technology by the time of the OSGeo sprint, June
16-22, and do most of the change over then. Meanwhile we should also
keep on making progress on 1.6.x bugs. And 1.7.x is still slow, some
core GeoTools changes are needed.

So we should make a plan for getting this work completed. From my
perspective I'd like to see 1.7.0 in release candidate status around the
end of June. From the TOPP side we can put some substantial resource in
to this: Andrea, Gabriel and Justin should have a majority of their time
available, and David and Arne can pitch in when our KML project
completes. If other people are available to help out do let us know so
we can plan on that.

I'm going to be at conferences and vacation for much of this time, so
I'd prefer a plan that everyone feels comfortable with committing to.
If we don't think it's reasonable to get all that done and stable by the
end of June then we can come up with something less ambitious. Perhaps just focusing on a really solid REST API along with core config? But this is one of the few times that paid or product priorities aren't
dominating, so it's an opportunity to really tighten up a core that will
allow us to move faster in the future.

We should also think about if we want to try to redo the UI, or if we
should just replace the backend technology and leave the html there. We
can put an interaction designer on making something that's more
intuitive, but in the interest of less moving parts it could be good to
hold off on that, and then call the results of that GeoServer 2.0. Could perhaps move off the 1.7.x release date and just aim for a super solid 2.0 by end of August?

In the interest of not having super long emails I'll bring this to a
close, would love to hear more people's thoughts on the next month or
two, what we should plan on and get done. And should coordinate the
rest of the plans with GeoTOols, ect.

best regards,

Chris

[jive]

Chris Holmes wrote:

So at TOPP we're taking a bit of a hiatus from paid work to focus on some core improvements on GeoServer which should hopefully make future development even faster. We've focused a lot on user facing features in the past couple years, neglecting some core annoyances.

Yeah!

Chief among those is the core configuration classes and the outdated struts (1) user interface technology. I believe Justin has been making progress on the configuration stuff, and it should hopefully get on to trunk soon.

I am glad to see that work picked up again.

The UI evaluation needs to be fired up again, and I'm hoping we can select a technology by the time of the OSGeo sprint, June 16-22, and do most of the change over then. Meanwhile we should also keep on making progress on 1.6.x bugs. And 1.7.x is still slow, some core GeoTools changes are needed.

Do you have a breakdown on what GeoTools changes are needed? We don't have any further changes scheduled for GeoTools trunk that I am aware of. There are some ideas (say a a better API for coverage access, a process api and such like) that are floating around but as far as I know they do not have a strict deadline or target GeoTools version.

So we should make a plan for getting this work completed. From my perspective I'd like to see 1.7.0 in release candidate status around the end of June.

So does 1.7.0 include a new user interface or not? Trying to figure out what is where when ... I see further in the email you are trying to make that decision as well.

From the TOPP side we can put some substantial resource in to this: Andrea, Gabriel and Justin should have a majority of their time available, and David and Arne can pitch in when our KML project completes. If other people are available to help out do let us know so we can plan on that.

End of June sounds fine on this end; we may end up cutting some of the unsupported modules from the GeoTools 2.5.x branch (such as process) rather than showing them to the world quite yet.

I'm going to be at conferences and vacation for much of this time, so I'd prefer a plan that everyone feels comfortable with committing to.
If we don't think it's reasonable to get all that done and stable by the end of June then we can come up with something less ambitious. Perhaps just focusing on a really solid REST API along with core config? But this is one of the few times that paid or product priorities aren't dominating, so it's an opportunity to really tighten up a core that will allow us to move faster in the future.

Agreed.

We should also think about if we want to try to redo the UI, or if we should just replace the backend technology and leave the html there. We can put an interaction designer on making something that's more intuitive, but in the interest of less moving parts it could be good to hold off on that, and then call the results of that GeoServer 2.0. Could perhaps move off the 1.7.x release date and just aim for a super solid 2.0 by end of August?

I am conflicted on this one; the amount of change / instability of the GeoTools level makes me want to call the next release GeoTools 3 / GeoServer 2 etc... I like the idea of a 2.0 release at the end of August. The timing looks good for the WPS work as well.

I am open to both suggestions, I can see it two ways:
- technology wise a 1.7 release backed on to the new config subsystem and a GeoTools 2.5 makes a lot of sense (walk before we can run). I would like to hear back on how that work is going from Justin.
- product wise it is nice to deploy all of these in an exciting GeoServer 2.0 release (with a line up of FOSS4G announcement & workshops)

In the interest of not having super long emails I'll bring this to a close, would love to hear more people's thoughts on the next month or two, what we should plan on and get done. And should coordinate the rest of the plans with GeoTools, ect.

Cheers,
Jody

[Justin_Deoliveira]

My thoughts:

Config stuff goes well, almost ready to commit, a few loose ends to tie up... but all unit + cite tests pass.. i have hand tested most of the UI, etc...

End of June for release candidate of 1.7.0 should be doable... but i fear its going to be a bit shaky for the first few release candidates. With the new config we are undoubtedly going to have regressions. Similar to on 1.6.x with the new dispatcher and xml parsing, etc... So we could start moving 1.7.0 toward stable by end of june... but i think it is going to take a few releases to work out the kinks for sure.

As for what to cover in 1.7.0... I would vote for the following:

* new config model (wrapped up in old model)
* address geotools performance issues
* rest api

I lump in REST api because it gives us something visible.. and is just downright cool :).

So that moves us to the sprint. It would be nice to get 1.7.0-RC1 out of the way before the sprint... but i am not sure that will happen. At a minimum, I would say we should get to a point where we can at least branch 1.7.x... and move it toward release. That would leave trunk open for the sprint. As to what to cover I would like to see the following:

* continue with config work (porting services and serialization/deserialization to the new model)
* new user interface

Now I know this is a lot... and I of course don't expect us to get them done in one week, but we could get a darn good start. And with the face time we could make sure we are all on the same page.

After the sprint we could continue working on the new stuff while moving 1.7.0 along to release. I think with these proposed changes... trunk will have to become 2.x.. Which I think makes sense because we are 1) breaking our disk storage format and 2) giving GeoServer a new face.

Apologies for the long email... trying to wrap this up. If people are on board with this plan it would mean that at a minimum we have to get the following done before the sprint:

1. initial config work
2. fix geotools performance
3. finish ui evaluation

I think the above list is doable... 1 is close to done and i am close to a patch for 2. The thing we are really lagging on at this point is the UI evaluation.

Thats it... please let me know if i have missed anything important... i am sure i have :).

-Justin

Chris Holmes wrote:

So at TOPP we're taking a bit of a hiatus from paid work to focus on
some core improvements on GeoServer which should hopefully make future
development even faster. We've focused a lot on user facing features in
the past couple years, neglecting some core annoyances.

Chief among those is the core configuration classes and the outdated
struts (1) user interface technology. I believe Justin has been making
progress on the configuration stuff, and it should hopefully get on to
trunk soon. The UI evaluation needs to be fired up again, and I'm
hoping we can select a technology by the time of the OSGeo sprint, June
16-22, and do most of the change over then. Meanwhile we should also
keep on making progress on 1.6.x bugs. And 1.7.x is still slow, some
core GeoTools changes are needed.

So we should make a plan for getting this work completed. From my
perspective I'd like to see 1.7.0 in release candidate status around the
end of June. From the TOPP side we can put some substantial resource in
to this: Andrea, Gabriel and Justin should have a majority of their time
available, and David and Arne can pitch in when our KML project
completes. If other people are available to help out do let us know so
we can plan on that.

I'm going to be at conferences and vacation for much of this time, so
I'd prefer a plan that everyone feels comfortable with committing to.
If we don't think it's reasonable to get all that done and stable by the
end of June then we can come up with something less ambitious. Perhaps just focusing on a really solid REST API along with core config? But this is one of the few times that paid or product priorities aren't
dominating, so it's an opportunity to really tighten up a core that will
allow us to move faster in the future.

We should also think about if we want to try to redo the UI, or if we
should just replace the backend technology and leave the html there. We
can put an interaction designer on making something that's more
intuitive, but in the interest of less moving parts it could be good to
hold off on that, and then call the results of that GeoServer 2.0. Could perhaps move off the 1.7.x release date and just aim for a super solid 2.0 by end of August?

In the interest of not having super long emails I'll bring this to a
close, would love to hear more people's thoughts on the next month or
two, what we should plan on and get done. And should coordinate the
rest of the plans with GeoTOols, ect.

best regards,

Chris

!DSPAM:4007,481f9e7f229314901796417!

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

!DSPAM:4007,481f9e7f229314901796417!

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4007,481f9e7f229314901796417!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

[Andrea_Aime3]

Justin Deoliveira ha scritto:

My thoughts:

Config stuff goes well, almost ready to commit, a few loose ends to tie up... but all unit + cite tests pass.. i have hand tested most of the UI, etc...

End of June for release candidate of 1.7.0 should be doable... but i fear its going to be a bit shaky for the first few release candidates. With the new config we are undoubtedly going to have regressions. Similar to on 1.6.x with the new dispatcher and xml parsing, etc... So we could start moving 1.7.0 toward stable by end of june... but i think it is going to take a few releases to work out the kinks for sure.

As for what to cover in 1.7.0... I would vote for the following:

* new config model (wrapped up in old model)
* address geotools performance issues
* rest api

I lump in REST api because it gives us something visible.. and is just downright cool :).

Hmmm. REST api is going to finally free all the people that are struggling trying to programmatically configure GeoServer, so it's
cool all right.
But (you expected a but, right?) how do we implement a good REST api
like http://geoserver.org/display/GEOSDOC/GeoServer+Resources without
a correspondent big change in the configuration and config storage
subsystem?

If we go for a cut down version of that proposal, it might work, but we
have to be careful to make it forward compatible. There are issues
to be solved there too (such as style treatment which is incompatible
with the current geoserver config).

So that moves us to the sprint. It would be nice to get 1.7.0-RC1 out of the way before the sprint... but i am not sure that will happen. At a minimum, I would say we should get to a point where we can at least branch 1.7.x... and move it toward release. That would leave trunk open for the sprint. As to what to cover I would like to see the following:

* continue with config work (porting services and serialization/deserialization to the new model)
* new user interface

Now I know this is a lot... and I of course don't expect us to get them done in one week, but we could get a darn good start. And with the face time we could make sure we are all on the same page.

Yeah, doing both seems quite ambitious. It might work if we just try
to do a UI technology conversion without trying to redo the UI face
as well, and spend the extra time making the UI talk to the new config
module directly. Of course, this would not really give GeoServer and
new face, but then again, I don't think we can handle changing the config, UI technology and UI face at the same time.
Moreover, giving GeoServer a new face would require some planning on
what the new workflow is, and that would put extra burdern on the preparation or turn the sprint into a discussion of how the new UI should look like.

After the sprint we could continue working on the new stuff while moving 1.7.0 along to release. I think with these proposed changes... trunk will have to become 2.x.. Which I think makes sense because we are 1) breaking our disk storage format and 2) giving GeoServer a new face.

Apologies for the long email... trying to wrap this up. If people are on board with this plan it would mean that at a minimum we have to get the following done before the sprint:

1. initial config work
2. fix geotools performance
3. finish ui evaluation

I think the above list is doable... 1 is close to done and i am close to a patch for 2. The thing we are really lagging on at this point is the UI evaluation.

So far we have an old Wicket prototype and a new Cocoon prototype.
I tried some other technologies, such as Struts2 + freemarker, but rapidly got out of my "comfort zone", that is, they rapidly became
too annoying to use for weekend projects.

Cheers
Andrea

[Justin_Deoliveira]

Hmmm. REST api is going to finally free all the people that are struggling trying to programmatically configure GeoServer, so it's
cool all right.
But (you expected a but, right?) how do we implement a good REST api
like http://geoserver.org/display/GEOSDOC/GeoServer+Resources without
a correspondent big change in the configuration and config storage
subsystem?

Well the way I see it going is that the rest stuff will be rewritten against the new configuration classes. I dont think it will be too much to switch over... and we can still keep the rest of the code base againast the old model... and things will still be in sync.

If we go for a cut down version of that proposal, it might work, but we
have to be careful to make it forward compatible. There are issues
to be solved there too (such as style treatment which is incompatible
with the current geoserver config).

Not quite sure I understand... fyi I did change the style class in the new model so its compatable with the old way. Is that what you mean?

Yeah, doing both seems quite ambitious. It might work if we just try
to do a UI technology conversion without trying to redo the UI face
as well, and spend the extra time making the UI talk to the new config
module directly. Of course, this would not really give GeoServer and
new face, but then again, I don't think we can handle changing the config, UI technology and UI face at the same time.
Moreover, giving GeoServer a new face would require some planning on
what the new workflow is, and that would put extra burdern on the preparation or turn the sprint into a discussion of how the new UI should look like.

How exactly would this work? Would we reuse the jsp's or something like that? Or just mock up something similar to what we have until we really research what would be a good UI workflow?

After the sprint we could continue working on the new stuff while moving 1.7.0 along to release. I think with these proposed changes... trunk will have to become 2.x.. Which I think makes sense because we are 1) breaking our disk storage format and 2) giving GeoServer a new face.

Apologies for the long email... trying to wrap this up. If people are on board with this plan it would mean that at a minimum we have to get the following done before the sprint:

1. initial config work
2. fix geotools performance
3. finish ui evaluation

I think the above list is doable... 1 is close to done and i am close to a patch for 2. The thing we are really lagging on at this point is the UI evaluation.

So far we have an old Wicket prototype and a new Cocoon prototype.
I tried some other technologies, such as Struts2 + freemarker, but rapidly got out of my "comfort zone", that is, they rapidly became
too annoying to use for weekend projects.

Cheers
Andrea

!DSPAM:4007,4820041544361015089218!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

[Andrea_Aime3]

Justin Deoliveira ha scritto:

Hmmm. REST api is going to finally free all the people that are struggling trying to programmatically configure GeoServer, so it's
cool all right.
But (you expected a but, right?) how do we implement a good REST api
like http://geoserver.org/display/GEOSDOC/GeoServer+Resources without
a correspondent big change in the configuration and config storage
subsystem?

Well the way I see it going is that the rest stuff will be rewritten against the new configuration classes. I dont think it will be too much to switch over... and we can still keep the rest of the code base againast the old model... and things will still be in sync.

I thought you wanted to get rest stuff on 1.7.x before branching (whilst
writing stuff directly against the new config would be trunk business?).
Moreover, are the concept of map and workspace covered in the new
configuration api?

If we go for a cut down version of that proposal, it might work, but we
have to be careful to make it forward compatible. There are issues
to be solved there too (such as style treatment which is incompatible
with the current geoserver config).

Not quite sure I understand... fyi I did change the style class in the new model so its compatable with the old way. Is that what you mean?

I did not look at the moment. I'm looking that that REST proposal that
does still call style a FeatureTypeStyle. The current configuration
(and imho any sane usage) should use UserStyle directly, instead of
splitting it into feature type styles....

Maybe I'm just misunderstanding, I thought you wanted to implement
that proposal on top of the current configuration classes before
branching. But I am confused anyways, since I don't remember seeing
a few concepts like "map" in the new config eiher
(which in that proposal does represent not only a layer grouping, but a
stand alone wms/wfs server no?)

Yeah, doing both seems quite ambitious. It might work if we just try
to do a UI technology conversion without trying to redo the UI face
as well, and spend the extra time making the UI talk to the new config
module directly. Of course, this would not really give GeoServer and
new face, but then again, I don't think we can handle changing the config, UI technology and UI face at the same time.
Moreover, giving GeoServer a new face would require some planning on
what the new workflow is, and that would put extra burdern on the preparation or turn the sprint into a discussion of how the new UI should look like.

How exactly would this work? Would we reuse the jsp's or something like that? Or just mock up something similar to what we have until we really research what would be a good UI workflow?

Mock up something similar to what we have now, yes. Otherwise we
have to decide what the new UI would look like as well, make a plan
for a better workflow. If we have one week only and a new technology
I don't think we'll also have the time to discuss and design a new
workflow and new look for the UI...

Cheers
Andres

[Justin_Deoliveira]

I thought you wanted to get rest stuff on 1.7.x before branching (whilst
writing stuff directly against the new config would be trunk business?).
Moreover, are the concept of map and workspace covered in the new
configuration api?

Confused... I did mean that. I also meant including the config stuff (wrapped up in the old model) on 1.7.x before branching as well.

The new config has the idea of a Map, but not a workspace. I dont think its necessary to model a workspace directly. I view a rest API as a "view" of our config, not necessarily a 1-1 mapping. I still have not heard a compelling reason for not reusing the idea of namespace as as workspace... maybe i am missing something fundamental.

I did not look at the moment. I'm looking that that REST proposal that
does still call style a FeatureTypeStyle. The current configuration
(and imho any sane usage) should use UserStyle directly, instead of
splitting it into feature type styles....

Hmm... which page are you looking at. I dont see it on this page:

http://geoserver.org/display/GEOSDOC/GeoServer+Resources

But yeah... not sure. Its tough because they really have separated it in the newest version of SLD... which references the SE spec. I am not sure. We could keep things the way they are (style = UserStyle) but as well have a finer grained class called FeatureTypeStyle. And have a UserStyle contain a collection of FeatureTypeStyles... I don't know. Its a tough call.

Mock up something similar to what we have now, yes. Otherwise we
have to decide what the new UI would look like as well, make a plan
for a better workflow. If we have one week only and a new technology
I don't think we'll also have the time to discuss and design a new
workflow and new look for the UI...

Works for me.

Cheers
Andres

!DSPAM:4007,48207dd8248781439371379!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

[jive]

Justin Deoliveira wrote:

Well the way I see it going is that the rest stuff will be rewritten against the new configuration classes. I dont think it will be too much to switch over... and we can still keep the rest of the code base againast the old model... and things will still be in sync.
  

I like that plan - make only the new config model available via the REST API. It gets the new config model some time in front of developers and gives us a real motivation to switch
the remaining modules over (ie so they can be seen by programmers that are using the REST API).

So far we have an old Wicket prototype and a new Cocoon prototype.
I tried some other technologies, such as Struts2 + freemarker, but rapidly got out of my "comfort zone", that is, they rapidly became
too annoying to use for weekend projects.
    

I suspect that the Cocoon prototype meets all of our requirements exception "fashion". Both cocoon and wicket provide a nice formal split between model and view; one using XSLT and the other using a fill in the blank template. Personally I have let whatever XSLT skills I had slide, I am not sure what the comfort zone is for others?

Jody

[Andrea_Aime3]

Jody Garnett ha scritto:

I suspect that the Cocoon prototype meets all of our requirements exception "fashion". Both cocoon and wicket provide a nice formal split between model and view; one using XSLT and the other using a fill in the blank template. Personally I have let whatever XSLT skills I had slide, I am not sure what the comfort zone is for others?

I prefer pure java code over xml+xslt for sure
Cheers
Andrea

[Andrea_Aime3]

Justin Deoliveira ha scritto:

I thought you wanted to get rest stuff on 1.7.x before branching (whilst
writing stuff directly against the new config would be trunk business?).
Moreover, are the concept of map and workspace covered in the new
configuration api?

Confused... I did mean that. I also meant including the config stuff (wrapped up in the old model) on 1.7.x before branching as well.

The new config has the idea of a Map, but not a workspace. I dont think its necessary to model a workspace directly. I view a rest API as a "view" of our config, not necessarily a 1-1 mapping. I still have not heard a compelling reason for not reusing the idea of namespace as as workspace... maybe i am missing something fundamental.

I thought the rest api was meant for geoserver configuration, not
only for access. I thus expected an API for configuration to have a 1-1
relationship between the rest api and the configuration.

I did not look at the moment. I'm looking that that REST proposal that
does still call style a FeatureTypeStyle. The current configuration
(and imho any sane usage) should use UserStyle directly, instead of
splitting it into feature type styles....

Hmm... which page are you looking at. I dont see it on this page:

http://geoserver.org/display/GEOSDOC/GeoServer+Resources

/geoserver/styles/<name> -> Return information about an existing style. (Can be represented as sld:FeatureTypeStyle.)

thought later in the "map" section you have:

/geoserver/maps/<name>/layers/<name>/styles/<name> ->
Return information about a named style. In general, a named style on a layer is a group of style resources from the /geoserver/styles container. (Corresponds to sld:NamedStyle.)

But yeah... not sure. Its tough because they really have separated it in the newest version of SLD... which references the SE spec. I am not sure. We could keep things the way they are (style = UserStyle) but as well have a finer grained class called FeatureTypeStyle. And have a UserStyle contain a collection of FeatureTypeStyles... I don't know. Its a tough call.

They are separated in the new version of SLD, but you are still
expected to use SLD 1.1 with a WMS no? SE 1.1 by itself does not
seem very useful to me. I mean, to do most maps you have to take
multiple feature type styles and lump them together in the proper
order. Heck, with feature type style alone we would not be able
to make the sample NY streets map we provide as a sample.

You said that the new configuration supports the idea of Map, but
it seems to me the new config idea of map is CompositeLayerInfo, which
is a sort of a layer group, whilst the one in the proposal acts
more like a mapserver mapfile, it makes you to create the style of
each layer by lumping toghether feature type styles, it serves
features, manages permissions and so on. From what I see it,
it defines a sort of a virtual server, that shows you only what
it is configured to make you see. I don't see anything like that
in the current configuration proposal... or I'm missing something?

Cheers
Andrea

[jive]

Jody Garnett wrote:

Well the way I see it going is that the rest stuff will be rewritten against the new configuration classes. I dont think it will be too much to switch over... and we can still keep the rest of the code base againast the old model... and things will still be in sync.
    

I like that plan - make only the new config model available via the REST API. It gets the new config model some time in front of developers and gives us a real motivation to switch the remaining modules over (ie so they can be seen by programmers that are using the REST API).
  

I have been talking this over with a co-worker (Martin Davis - perhaps you have heard of him). He had a couple ideas, one of which is bad but I will share anyways... basically he wondered if we could "eat our own dog food" with respect to the REST API backing onto the new config subsystem. Wither a javascript or wicket application (ie separate application) that communicates to the core geoserver module using the REST API.

I personally hate the idea of writing our own javascript front end (sure we could do it; but it would be a maintenance and testing hassle). I am not too sure of the idea of making a Wicket application that fires changes over to geoserver via the a REST api ... but it gives me an idea.

Could we use Andrea's spring remoting magic, publish the same config API out via REST and via spring remoting (for a separate Wicket application?).

I am not sure if this idea holds any appeal. It may be a bad product idea to introduce a REST API as a distinct layer; it would be way too easy make new functionality quickly via REST and forget to keep the web client up to date and in sync.

Jody

[Justin_Deoliveira]

I thought the rest api was meant for geoserver configuration, not
only for access. I thus expected an API for configuration to have a 1-1
relationship between the rest api and the configuration.

I think we just have a different of opinion here... but I dont think it necessarily have to. I expect GeoServer to support REST api's in which we dont have a one to one object model for... i mean... this is the whole point of frameworks like restlet is it not? To do the mapping from the rest structure to your actual objects.

Anyways... I think it makes sense to have a 1-1 relationship in some cases... but to come up with a new config object soley for the reason that it is in a rest api seems a bit off to me. I could be wrong... and others better at REST may differ.

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

[jive]

Andrea Aime wrote:

They are separated in the new version of SLD, but you are still
expected to use SLD 1.1 with a WMS no? SE 1.1 by itself does not
seem very useful to me. I mean, to do most maps you have to take
multiple feature type styles and lump them together in the proper
order. Heck, with feature type style alone we would not be able
to make the sample NY streets map we provide as a sample.
  

There are two ways to consider it; SLD is the styling for an "entire" map; all the layers etc... the SE part is what we associate
with each individual layer (ie what we should save to associate with each named style we publish), the scope is limited to a specific FeatureType.

Bigger picture the scope of an SE document is for a FeatureType (and all its children). The idea is to store SE documents for the different FeatureTypes in your system and bring them all together into an SLD document for a specific map. In the uDig catalog we basically use the SE portion of SLD 1.0 and ignore all the rest as book keeping .... since we focus on rendering one layer at a time.

Jody

[Luca_Morandini2]

Jody Garnett wrote:

I am not sure if this idea holds any appeal. It may be a bad product idea to introduce a REST API as a distinct layer; it would be way too easy make new functionality quickly via REST and forget to keep the web client up to date and in sync.

On the other hand...
1) It would put to test the soundness of the RESTful API (eat your own
dog-food).
2) It would allow the building of mapserver-appliances (GeoServer instances
without UI) useful in production environment.
3) It would reduce the footprint of GeoServer and decouple it from the
front-end baggage (be it Struts, Wicket, Cocoon, whatever).
4) It might even lessen the level of anxiety of Andrea , who fears reduced productivity when juggling with technologies other than Java (just split the team in two: one taking care of "core" GeoServer, the other of the UI).

Regards,

--------------------
    Luca Morandini
www.lucamorandini.it
--------------------

[Saul_Farber]

I agree with Luca on this one. I think "eating our own dog-food" is the
surest and best way to properly develop and constantly test the REST
api. Plus it puts all gui's on a level playing field.

FlexJSON + the config back-end + REST for configuration would seem to
allow everyone to just get on with developing the core engine, while
letting folks who want to do the front-end work figure out the best way
to do that...and keep it seperate.

--saul

On Tue, 2008-05-06 at 11:21 -0700, Jody Garnett wrote:

Jody Garnett wrote:
>> Well the way I see it going is that the rest stuff will be rewritten
>> against the new configuration classes. I dont think it will be too much
>> to switch over... and we can still keep the rest of the code base
>> againast the old model... and things will still be in sync.
>>
> I like that plan - make only the new config model available via the REST API. It gets the new config model some time in front of developers and gives us a real motivation to switch the remaining modules over (ie so they can be seen by programmers that
> are using the REST API).
>
I have been talking this over with a co-worker (Martin Davis - perhaps
you have heard of him). He had a couple ideas, one of which is bad but I
will share anyways... basically he wondered if we could "eat our own dog
food" with respect to the REST API backing onto the new config
subsystem. Wither a javascript or wicket application (ie separate
application) that communicates to the core geoserver module using the
REST API.

I personally hate the idea of writing our own javascript front end (sure
we could do it; but it would be a maintenance and testing hassle). I am
not too sure of the idea of making a Wicket application that fires
changes over to geoserver via the a REST api ... but it gives me an idea.

Could we use Andrea's spring remoting magic, publish the same config API
out via REST and via spring remoting (for a separate Wicket application?).

I am not sure if this idea holds any appeal. It may be a bad product
idea to introduce a REST API as a distinct layer; it would be way too
easy make new functionality quickly via REST and forget to keep the web
client up to date and in sync.

Jody

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Andrea_Aime3]

Luca Morandini ha scritto:

Jody Garnett wrote:

I am not sure if this idea holds any appeal. It may be a bad product idea to introduce a REST API as a distinct layer; it would be way too easy make new functionality quickly via REST and forget to keep the web client up to date and in sync.

On the other hand...
1) It would put to test the soundness of the RESTful API (eat your own
dog-food).
2) It would allow the building of mapserver-appliances (GeoServer instances
without UI) useful in production environment.
3) It would reduce the footprint of GeoServer and decouple it from the
front-end baggage (be it Struts, Wicket, Cocoon, whatever).
4) It might even lessen the level of anxiety of Andrea , who fears reduced productivity when juggling with technologies other than Java (just split the team in two: one taking care of "core" GeoServer, the other of the UI).

My plan was to tackle this by making the UI pluggable, but still pure java. That is, each module has its own configuration UI module, if you
don't want to use it, don't include its jar and you're done (just like
you do if you don't want a specific datastore).

That would have allowed to make the UI in pure java and still let it
be optional

Cheers
Andrea

[Andrea_Aime3]

Jody Garnett ha scritto:

Andrea Aime wrote:

They are separated in the new version of SLD, but you are still
expected to use SLD 1.1 with a WMS no? SE 1.1 by itself does not
seem very useful to me. I mean, to do most maps you have to take
multiple feature type styles and lump them together in the proper
order. Heck, with feature type style alone we would not be able
to make the sample NY streets map we provide as a sample.
  

There are two ways to consider it; SLD is the styling for an "entire" map; all the layers etc... the SE part is what we associate
with each individual layer (ie what we should save to associate with each named style we publish), the scope is limited to a specific FeatureType.

Bigger picture the scope of an SE document is for a FeatureType (and all its children). The idea is to store SE documents for the different FeatureTypes in your system and bring them all together into an SLD document for a specific map. In the uDig catalog we basically use the SE portion of SLD 1.0 and ignore all the rest as book keeping .... since we focus on rendering one layer at a time.

And you forget to take care of needs such as road casing and, more in
general, composite symbology that styles a single layer by doing so,
right? With that approach you cannot have a "highway" style, but only
a "thin line", "thick line" ones that you have to apply in the right
order on two layers that happen to use the same data...

Cheers
Andrea

[Andrea_Aime3]

Saul Farber ha scritto:

I agree with Luca on this one. I think "eating our own dog-food" is the
surest and best way to properly develop and constantly test the REST
api. Plus it puts all gui's on a level playing field.

FlexJSON + the config back-end + REST for configuration would seem to
allow everyone to just get on with developing the core engine, while
letting folks who want to do the front-end work figure out the best way
to do that...and keep it seperate.

The "eat your own dog food" argument is good, but I expect the REST
api to have its own battery of unit and functional tests (my position
atm is to vote -1 for any community module that tries to graduate
without a decent testing coverage).

The idea that we have to rely on a UI managed by a different group of
developers strikes me as odd and risky thought.

Up to this point the UI and config have been really static only
because they were damn hard to modify. But that is going to change
with the new code, we're no more going to stop a config change
because it's too darn hard to implement. So whoever want to maintain
a brand new UI is up to a fast ride.

Let's assume we have "folks who want to do the front-end work figure
out the best way to do that". Can we rely on them to make a change to
the UI each time we change the configuration? Or should we release
crippled GeoServer versions that allow new configuration to be
managed only by the REST api only because the UI group did not make
it?
I already hear someone saying "xml + rest is ok, I don't need a UI".
Lucky you that you can manage without, but please understand you're
within a minority, imho most people will need a UI (heck, I know I do
want one, playing by hand with xml, curl and manual url fiddling is
certainly handy on occasion, but I would not want to be limited
to it).

Imho the default UI should be something the main, stable, guaranteed
to be there development group can comfortably work on, so that the
UI stays up to date as well as the REST api.
If a new group of pure UI developers want to roll their own UI
sitting on top of REST, make it better that the default one,
and keep it up to date as GeoServer evolves, more power to them,
and more power to GeoServer itself.

But I'm personally against the idea of relying on a UI that I cannot
work comfortably against, that is to be maintained by a "UI group"
that's not there, and that has made no commitment of working on it
at the same pace as GeoServer evolves.

Give me the commitment needed, and then the risk may turn into
an advantage: if we can rely on this group solid (be always there
to update the UI before a release, not vanish in thin air after a
few months) then we have more time to concentrate on the backend.

Flame away
Cheers
Andrea

[Luca_Morandini2]

Andrea Aime wrote:

My plan was to tackle this by making the UI pluggable, but still pure java.

Pure Java... wow ! Do you plan to write your mark-up using servlets ?

That is, each module has its own configuration UI module, if you
don't want to use it, don't include its jar and you're done (just like
you do if you don't want a specific datastore).

As long as there are two packages for every module (the module itself and the UI), that's perfectly sound. However, there would probably be some dependencies amongst UI modules (authentication&authorization would be needed by UI every module, for instance).

Therefore, the GeoServer packaging options may look like this:
1) Development (all-but-the-kitchen-sink).
2) Appliance (just the core functionality, without fancy stuff or the UI).
3) A-la-carte: pick your own modules (possibly using Maven) with or without the UI.

Regards,

--------------------
    Luca Morandini
www.lucamorandini.it
--------------------

[Andrea_Aime3]

Luca Morandini ha scritto:

Andrea Aime wrote:

My plan was to tackle this by making the UI pluggable, but still pure java.

Pure Java... wow ! Do you plan to write your mark-up using servlets ?

Wicket is as pure java as it gets, you only have to write a (pure) html
file with ids and then wicket uses it as a template.
Well... using GWT one could really make it totally pure java afaik,
but my issue is not going to far away from my comfort zone, not
to kill everything that's not java (GWT is tempting, but I would
not be able to make the UI modular the same ways datastores are).

That is, each module has its own configuration UI module, if you
don't want to use it, don't include its jar and you're done (just like
you do if you don't want a specific datastore).

As long as there are two packages for every module (the module itself and the UI), that's perfectly sound. However, there would probably be some dependencies amongst UI modules (authentication&authorization would be needed by UI every module, for instance).

Yep, correct

Therefore, the GeoServer packaging options may look like this:
1) Development (all-but-the-kitchen-sink).
2) Appliance (just the core functionality, without fancy stuff or the UI).
3) A-la-carte: pick your own modules (possibly using Maven) with or without the UI.

Yeah, the plan was to make it a la carte.

Cheers
Andrea