I was stick this week with SLD WMS stuff, so I'm letting the refactoring
for next week.
I wonder if you know about any advance in the SAX sld parser mentioned
in some previous email?
Jody, what's the status of the new sld stuff? We may be interested in
trying it out in geoserver.
since the current dom based one is preventing me
of doing GetMap SLD.
What's the problem with the dom one?
If there are no progress with it I guess I can
finish the pending parts of the current parser at least to have SLD
GetMap in time, or may be start/continue the sax work?
Let's see what Jody says. It's uses DavidZ's new XML framework, so it
could be good to get you trying it out, since there is a thought to
migrate GeoServer over to it. It just needs a good bit more
documentatoin. The root idea is quite nice though, it's built on top of
sax, but makes easy a few things that are quite hard. But it remains to
be seen how easy it will be for us to debug it. We'll get David working
on it too.
GetLegendGraphic is working nicely from some days ago and will commit
three sample requests for congUserBasic in a few minutes.
Cool.
Some more comments inline.
On Wed, 2005-03-09 at 21:38 -0500, Chris Holmes wrote:
> > There is also the fact that the code base is getting a monster and
> > difficult to follow, due to the way packages are organized. This, along
> > with the plan to separate services as plugins, goes to the need of
> > refactoring the packages on a service base. Something like-
> >
> > org.vfny.geoserver.wms.*
> > org.vfny.geoserver.wfs.*
> > org.vfny.geoserver.core.*
> > org.vfny.geoserver.config.*
> > etc.
> >
> > If you're ok with this, I can manage to start doing this refactoring in
> > a slight fashion, provided that the build is not broken.
> Hey Gabriel, when are you thinking of going forward with this? David and
> I both very much want to see it done, and we're trying to figure out
> scheduling for the month. We're thinking of a geoserver 1.3-beta
> hopefully sometime next week,
I'm not sure I can manage to do the refactor this very week since the
thing that scares me is the config stuff. How about tue/wed next week?
Let's plan on wednesday then. Hopefully DavidB can get out a release over
monday tuesday, with the mapbuilder shapefiles that Cameron wants in.
After that is out we can do the refactoring.
> just to show the basics of what has been
> done, let users hit geotools 2.1. And then a 1.3.0 at the end of the
> month, with just more solid sld support,
As said, it depends on sld parser status, but I'm pretty positive about
having SLD suppor for the end of the month. At least with SLD and
SLD_BODY (remote document and inline document) for GetMap. Not so sure
for POST, although I'm not sure it is blocker, may be SLD and SLD_BODY
is enough for this demo?
SLD post would be nice. But it should be trivial if it's working
otherwise, as we already have a GetMap object to store the values - we
just need a reader that reads the SLD and the few extra fields in a post
request.
> working off of 2.1, and hopefully
> the geoserver_home idea. Are you going to be able to do the refactoring
> this month? Also, do consider treating the struts stuff
> (config/form/action) the same way as you do request/response/servlet - as
> something you would distribute into the w*s service. Each of the struts
> things is divided up into wfs/wms/data and all. Also, you may consider
> splitting 'data' stuff out of core - the management of the stores and all.
My first impression was that data should be on core and all services and
config have their own module and be separated as plugin in the near
future,so they just can stick to the core data components.
For instance, WMS is in need of its own data config to allow nesting
layers, but I see it as selecting a featuretype from the core data
component and specifying where in the layer's tree it should be,
hopefully using a nice tree based editor and a map preview with
mapbuilder.
So please explain me a bit more your idea of taking data stuff out of
core so I can make a better picture of the whole idea. Or do you mean
only data config (aka, struts stuff?)
I actually don't have super strong opinions about this, it's more Jody.
Maybe he will sound in. If not, then yeah, leave data stuff in core. I
think the main thing he wants is to make sure the service specific struts
stuff is in the service area. So the struts stuff (action, config, form)
that is specific to WMS should go in the wms area. So yeah, just figure
out how you envision it, and send an email to the list. And then just go
for it after David gets 1.3-beta out. And do try to use svn move, so we
can keep version history.
> But that I'm less sure about. Basically you should come up with a full
> plan of the refactoring you are planning, and let us review it, and we
> can move forward. We just need things stable by the end of the month, in
> time for udig.
right.
>
> > May be we should plan a maven style project model for 1.4?
> You mean use maven? I'm not against it, but I'm not sure of the benefits.
> Does it gain us anything big? That we're missing now? If there's not
> then I don't see a big reason to do the extra work of rewriting the
> targets. We could perhaps benefit from sharing nightly build jars from
> geotools that udig uses. But we don't have all the crazy depenancy
> ordering.
the idea of moving to maven is more for mid-time future than for right
now. As I see it, what have to be done for this release is the
refactoring so it will be easier in the future to move each service to
its own module, so we can create a jar for each module and let them
register as a service with the FactoryFinder stuff. But we need this
first iteration to be sure what exactly nust be in core. This way, we'll
can work on services separatelly, just like we do in geotools modules,
and other people will can add a service by just rolling in a jar.
Cool.
I need to inspect deeply the config stuff too, bu had the idea that each
module (service) could provide its own congfiguration pages inside its
jar. May sound crazy, and may be it is, but I see it as follows:
- a service is developed in its own "module". It provides both its
funtionality, which it attached to the core module, and its
configuration stuff.
- a service is rolled in as a jar, which is deployed to geoserver libs.
and its configuration pages are inside that jar, but in its own jar.
- core has a structure/template for configuration that makes it easy to
add config pages
- when the application is deployed by the servlet container, it looks
service factories, and asks each factory for a resource containing its
config stuff. If found, geoserver just deploys the jar content to the
config pages directory, uncompressing all the html, jsp, images, etc. to
that concrete directory.
So we have a core config for setting up available datastores and each
service provide its own, specialized, config stuff, that sticks on top
of the config infrastructure and the core data.
No, I don't think that's crazy, indeed that's how I would like things to
be. The one question I have is if we force the plug-ins to do struts, or
if we let them do their own gui if they want... I ask because we will be
integrating with geonetwork, and they have their own nice, debugged, gui.
It would be silly to have them rewrite it just for the initial
integration. I think eventually we should all sync up on the same gui,
but it might be good to try to find something other than struts, as I
don't think any geoserver developers are exactly in love with it.
An ideal would be to have this html based configuration application but
being able to configure geoserver from another ways, like from uDig. So
we can think on the configuration service idea later, which is, defining
service config just like another service with its own operations (like
putStyles does).
Yeah, the dto objects, our weird extra layer of indirection, should allow
for this. Right now they can be created through the struts stuff, or read
from xml files. But others could do it as well - udig could just insert
new dto's directly I believe.
And of cuorse, I'm sure there are a better way of doing it, so if one of
you knows about something similar say it, or may be this is a stupidity
and you just wish to have a config module that takes care of the
configuration for all the services?
If not a so bad idea, I'm all for migrating the config stuff to its own
"module" as a fist step in that direction.
Yeah, I think this could work for me. The core struts stuff is very core,
but not at the level of dtos and core data. It lives in its own module,
and then the other services can choose to utilize the core struts stuff
for their configuration. Or early versions can just use file based
configuration. It would be nice to make the xml config file readers more
modular, so that the wms reading stuff would be in wms, but they would all
read the same file, and build up the full configuration. Also, another
design goal for the future is reading config from a database, instead of
relying on files.
David is going to be working on the GEOSERVER_HOME idea, you specify
configuration in a home directory. Would be cool if you could also just
set up connection params and tablenames to read the config from in your
geoserver home directory.
Ok, I'm going to do a big jira organization today. Since we now have
three developers working away (well, I will drop away for a bit, but
should come back relatively soon), we should use jira to coordinate and
see what we are all working on. So Gabriel do try to put the stuff that
you are working on in there.
Chris
Hope to hear from you.
Gabriel.
>
> Chris
>
> >
> > please let me know what you think,
> >
> > best regards,
> >
--