To lead to wider acceptance of GeoServer we need to make configuration of the server a lot easier. Ideally we can abstract everything away from the xml files and have a nice web based graphical user interface. That way users can get started right away, and don't have to learn all sorts of syntax and tools to get up and running. Combined with the built-in tomcat server this will provide a very powerful out of box wfs solution.
CodeHaus Comment From: cholmes - Time: Wed, 10 Dec 2003 15:51:16 -0600
<p>IRC chat discussion on this issue from Dec 9, 2003</p>
<p><cholmes> Shall we get started?
<jgarnett> I suppose we shall
<cholmes> Did everyone read Jody's email to geoserver-devel?
<jgarnett> My email did not really answer cameron's question: namely provide a straw man
<CameronShorter> Thanks Jody, it is a good start.
<jgarnett> Did I completely miss anything chris?
<cholmes> Um featureTypeConfig?
<jgarnett> I think I put that under CatalogConfig (I got a bit lost)
<CameronShorter> Jody, are you planning to provide a front end to the database? Ie, provide a form that allows a user to define what features the WFS will support.
<jgarnett> I am not sure what I am planning <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/> That is why I wanted to have this little meeting
<jgarnett> I think what is actually wanted is to let GeoServer be useable by mere mortals
<CameronShorter> I think one of the biggest barriers to setting up Geoserver is installing PostGIS.
<jgarnett> Chris? What did you want to acomplish?
<groldan> I think one thing is if geotools' datastore is introspective enough to build a datastore configuration UI
<CameronShorter> I'd like to see some hosting bodies setting up PostGIS and your config web pages, then allow users to build their own WFS data structure.
<cholmes> I'd like to get on the same page of what should happen with config.
<groldan> actually we have mandatory and optional parameters with their types, It should be enough
<jgarnett> You will fogive me: I am slow today...
<cholmes> I just wrote a 'recipe' for the wfs cookbook, and it hit on a few things that could certainly be made easier.
<jgarnett> cameron: I am sure you are right, does shapefile support help take away the Postgis hurdle?
<jgarnett> groldan: that is a great idea
<CameronShorter> Jody, yes. Although I have not tried to set it up.
<cholmes> Yeah, I don't think there's much we can do to make the actual installation of postgis easier. But we can support a number of data formats, so that people who already have stuff set up can easily get started.
<jgarnett> I would love to have the GeoServer distribution work right of the box with toy shapefiles to get people going
<cholmes> With geoserver 1.0.* a shapefile is included and works out of box.
<CameronShorter> However my original point is still valid, I'd like a user to be able to entirely configure and maintain a WFS through a web page.
<CameronShorter> Chris, great.
<cholmes> But yes, exactly as cameron says, you still need ant, so we need a way to just configure on a web page.
<jgarnett> I did not understand the last bit, why do we need ant?
<CameronShorter> Chris, does your out of the box solution provide transaction support?
<cholmes> Because right now 'out of box' means acquire ant, run each time you change the config, and move the war over to your container.
<cholmes> Shapefile in 1.0.* does not support transactions, so no. I think it might work with 1.1, but I haven't tested.
<cholmes> But it's really <em>much</em> better to use a database.
<jgarnett> That is a good point about ant being used to generate the war. Is there a better place to store our configuration files?
<CameronShorter> Out of box is great for finding new users. They run out of box. See it works, then are prepared to spend more time configuring the database.
<cholmes> Yeah, we have the built-in tomcat, which makes it so users do not even have to find and install a servlet container.
<cholmes> Ok, so at a minimum, from a users perspective, I feel there's a few things we need:
<groldan> I think a geoserver release would come with a client too, one that works with the sample data and have hints to customize it
<cholmes> *webpage to configure the global config options.
<cholmes> *webpage to add new featureTypes
<cholmes> *webpage to add new datastores.
<cholmes> *automatic generation of schemas from the geotools featureTypes
<cholmes> *automatic generation of the latLonBoundingBox.
<cholmes> *a simple and easy way to save the configuration files.
<cholmes> Yeah, I agree a good client would be really nice.
<cholmes> But I feel like it's a fairly involved project.
<CameronShorter> Groldan, we are working on a WFS client at <a href="http://mapbuilder.sf.net" class="external-link" rel="nofollow">http://mapbuilder.sf.net</a> (the people from geocleint are on this project). But we don't have something ready to deliver yet.
<groldan> yeah, it is <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/sad.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<CameronShorter> Feel free to join us if you want. <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<CameronShorter> Chris, that is a good list.
<CameronShorter> What is a datasource?
<groldan> cool, unfortunatelly I'm working in a SVG client but it's not conformant, since I have a middleware webapp between it and geoserver
<cholmes> What language are you guys coding in? And how often does anyone actually code?
<groldan> but it can be modified a bit...
<groldan> great, I'll take a look
<CameronShorter> Groldan, we also have a SVG client, (in bits and pieces). It would be good if you could join the list and discus your product with the authors of our SVG client.
<jgarnett> So chris did we miss anything in your list? Any reason a user would have to look at an XML config file if we hit everything on your list?
<groldan> that will be great Cameron. Unfortunatelly again, I'll can't until middle january, due to a mad deadline
<CameronShorter> Chris: JSP, XML, XSL, java, a little struts ... (but I won't have time to work on geoserver). I'm happy to consult with design if you like.
<cholmes> I don't believe so. Well I guess there's also WMS config and validation config.
<jgarnett> Question I saw some SVG code in GeoServer. Is that ready to go or did it need the middleware webapp?
<cholmes> Ok, I might be interested in awhile...I'll get in touch when I need a design overview.
<groldan> about WMS config, it should be interesting if we can create styles...
<groldan> no it don't need it
<jgarnett> Styles is a whole lot of fun <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/sad.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<groldan> the problem is that the SVG encoder does not parses styles yet
<CameronShorter> Jody, I think it is ready to go, but I think it has extensions to the WFS protocol.
<cholmes> Yeah, I was just of that. Probably outside the scope for this config iteration, but should plan for it.
<groldan> but it's a lot faster <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<cholmes> (I was just thinking of that)
<jgarnett> I was hoping to use it to provide some visual feed back when setting up the validation configuration
<CameronShorter> You might want to look at: <a href="http://www.gworks.ca/geoclientx/" class="external-link" rel="nofollow">http://www.gworks.ca/geoclientx/</a> (It is a HTML version of the SVG client)
<cholmes> Another nice thing to have in config would be to visualize the data, Jody I think you were talking about this for validation stuff. But basically be able to see the data with the wms easily.
<groldan> currently I'm using that SVG encoder to get SVG streamed content to my client, but since the styles are already declared as CSS in the client itself, I had no time to improve the encoder styling
<CameronShorter> Chris, that would be good, but I suggest the visualisation wait until version 2.
<groldan> the extensions to the WMS protocol I have introduced for the SVG encoder are for getting attribute data and reducing the content size to the minimun possible
<jgarnett> Sorry I don't think I can wait on that one <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/sad.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<CameronShorter> Hopefully you should be able to use some of our work from mapbuilder.
<groldan> but you can use it without them
<jgarnett> I am suppose to deiliver "a visual configuration tool" for the validation stuff. My alternative is to make a JUMP plug-in...
<CameronShorter> Groldan, can you please email me so I can contact you afer IRC: cameron At shorter.net
<groldan> ok, no problem
<CameronShorter> Yes, extensions to jump is a good idea.
<cholmes> I don't think it should be too difficult Jody, you'll just have to figure out what wms request to use.
<cholmes> So that's about what we need from a users perspective.
<cholmes> From a developers perspective I think we need to seperate things out a bit more.
<jgarnett> Shall we talk code for a bit then? Does anyone have recent STRUTS experience?
<cholmes> Would be nice if we could do some of the things Simon Rass was talking about, making interfaces that can be implemeted, so that config could be stored in a database instead of xml files, for example.
<jgarnett> +1 for seperating things out
<CameronShorter> About 18 months old for me.
<cholmes> I looked at struts a bit, and if none of us know it I don't see a real compelling reason to use it.
<CameronShorter> Jody, I think STRUTS would be a good tool to use for this.
<cholmes> Cameron, why?
<CameronShorter> Struts allows you to build WIDGETS for a HTML display.
<jgarnett> I am sure it would be, just worried about ramp up time. Struts has a good MVC separation. Does a lot of the book keeping and so on.
<CameronShorter> Each widget is a module of JSP code.
<CameronShorter> You then have a main page which pulls in all the widgets.
<cholmes> The other issue of STRUTS is that it's apache licensed, which is incompatible with the GPL
<jgarnett> I think we would just be using struts, not extending it. Which should be fine with GPL?
<cholmes> If it was really important we could maybe change GeoServer's license, but I don't know that just using struts is a good enough reason.
<cholmes> I think you have to still say 'powered by apache'.
<cholmes> The gpl apache incompatability is really lame.
<CameronShorter> If you only have one main page that you plan to design, then STRUTS will provide little benefit.
<cholmes> But it's basically that with the gpl you have to pass the code on, but the having the 'powered by apache' is somehow incompatible.
<CameronShorter> Also, STRUTS is good for reusing widgets - so if you don't plan to reuse widgets in other projects, then again no need for STRUTS.
<CameronShorter> If you want to go with STRUTS it would be worth contacting the authors and asking for a GPL licence. They may give it to you.
<CameronShorter> I've got to go in a minute. Any questions for me before I go?
<jgarnett> Even just working through chris's list we should have half a dozen screens. When I get into validation I would certaintly appricate the reuse struts would provide
<cholmes> Yeah, how long do you think it takes to 'ramp up' with STRUTS?
<cholmes> I mean, neither Jody nor I know struts at all, how many days would we need to spend learning it to be able to work with it?
<jgarnett> It took me a couple days last time chris, but I had a already working project to help out, so it was not too bad
<cholmes> Oh, you do know struts? I thought you didn't.
<CameronShorter> Yes, a few days trawling the docs, to a week.
<CameronShorter> (I'm guessing).
<jgarnett> I do know a little struts, but not recent. I am going to go buy a book if that is what we decide to use.
<cholmes> Yeah, I guess I could do the same.
<TheSteveMonkey> look at spring
<TheSteveMonkey> I do lots of struts
<cholmes> At spring?
<jgarnett> I am just wondering if struts, and a detailed design is over kill for what we want to acomplish?
<CameronShorter> We were very impressed with STRUTS after using it at Social Change. Primarilly for it's reuse capabilities.
<TheSteveMonkey> I love struts but if you want to repurpose to an applet or something then you got problem,s
<TheSteveMonkey> spring is another framework or webwork which are both supposed to be more portable
<TheSteveMonkey> Are you using forms?
<jgarnett> We have not got that far yet <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<CameronShorter> You won't add much value to your first project using STRUTS, but future projects are much easier because you cut and paste widets into pages.
<TheSteveMonkey> And it makes working with webforms a breeze
<jgarnett> I am going to be very temped to give struts/spring a miss and just BFI for the first cut
<jgarnett> BFI - brute force and ignorance
<TheSteveMonkey> I am sorry I missed the earlier convo
<TheSteveMonkey> what are we trying to do
<jgarnett> We are trying to place a user interface ontop of GeoServer
<jgarnett> Allowing web based adminstration/setup rather than hand editing xml files
<TheSteveMonkey> its all about struts then
<TheSteveMonkey> the tomcat manager appilcation was built in struts
<cholmes> How do you run the tomcat manager? I've never tried it out.
<TheSteveMonkey> you turn it on in the server.xml file. Look at the doco
<TheSteveMonkey> its in there
<jgarnett> So chris why don't we look into GPL / struts conflict. If there is a conflict we can just use BFI
<TheSteveMonkey> sorry not the manager
<cholmes> Ok, I think it might actually work out ok. I'll talk to Rob and see what he says. We actually already do have some apache stuff in GeoServer, but it's just not advertised or obvious (in zserver module)
<TheSteveMonkey> here we go <a href="http://www.onjava.com/pub/a/onjava/2003/06/25/tomcat_tips.html" class="external-link" rel="nofollow">http://www.onjava.com/pub/a/onjava/2003/06/25/tomcat_tips.html</a>
<cholmes> Cool. Thanks, I'll check it out.
<TheSteveMonkey> np and let me know if you want to talk Struts
<TheSteveMonkey> are we going to be talking do a DB at all or just a web interface to some underlying daemon
<jgarnett> I am a bit confused .. what do you mean?
<TheSteveMonkey> what will the web interface be talking to?
<TheSteveMonkey> a servlet acting like a daemon
<jgarnett> A j2ee application</p>
<li>TheSteveMonkey trys to find the thread in teh irc logs
<jgarnett> "GeoServer": a Web Map Server/ Web Feature Server hybrid
<jgarnett> chris shall we talk about break apart the Config classes? I don't think we can use them as they now stand
<TheSteveMonkey> so the web interface is for making request to the server or is it for changing settings for the servers
<cholmes> Changing the settings.
<TheSteveMonkey> so it needs to change the settings and restart the webapp
<cholmes> (though it may be useful to also make some requests)</li>
<li>jmacgill wakes up
<cholmes> Yes, it needs to be able to do that.
<TheSteveMonkey> where are the settings for the server stored, xml file, DB, flat text file...
<jmacgill> so changes would be persisted by changing the xml config files?
<cholmes> Right now xml file.
<jmacgill> (hi all btw, just passing)
<cholmes> Yes James. Though it would be nice if we could have interfaces for implementors to persist in other ways.
<cholmes> At least one of our users was interested in that, at least.
<cholmes> If it's not too difficult to do it might be worthwhile, so that geoserver could more easily be integrated into other gis systems.
<-- TheSteveMonkey has quit (Read error: 104 (Connection reset by peer))
<cholmes> Eventually it might be nice to roll in a number of the config stuff into the concept of a geotools Catalog, that could handle the persistance, and manage the connections to the various datastores, as well as their meta information.
--> TheSteveMonkey (~Steve0@yesh.stat.yale.edu) has joined #geotools
<jgarnett> I actually think a lot of the metadata information could be stored by ArcSDE for the ArcSDE DataStore....
<CameronShorter> Can someone please collect logs. (I've got to go now). Bye.
<-- CameronShorter has quit ("Client exiting")
<jgarnett> Thanks cameron
<cholmes> So it would be nice if we had a way for datastores to provide more meta information?
<TheSteveMonkey> sorry, I got dropped
<groldan> yeah, I think so jgarnett, but have no worked with it, although I have seen some classes in the esri's SDE java api
<cholmes> It's ok, you didn't miss much, just that it might be nice to roll some of the config that geoserver does into geotools.
<groldan> at leas for feature type metadata, yes
<jgarnett> Well lets go for broke. Lets take over the geotools2 Catalog api and make it our "pure" data model. We can have our Config file read in the XML to populate the model.
<jgarnett> Should at least take care of CatalogConfig, FeatureTypeConfig, and Namespace
<groldan> as shapefiles could come with xml metadata files,SDE with db backed metadata, etc. PostGis would can implement it too
<cholmes> Yeah, I was thinking along the same lines. Have the Catalog be an interface, and implementations will be able to persist themselves according to the implementation.
<cholmes> So we'll start out with geoserver structure of xml files, but others can be implemented as well.
<jgarnett> The main thing that worried me was the use of singletons
<jgarnett> Would be hard to try out your configuration before making it live
<groldan> I was thinking the same
<cholmes> How so? How would you try out your configuration before making it live?
<groldan> since for changing config you should use a memento, until changes got applied
<jgarnett> All sorts of classes "cache" the server config as a local member...
<cholmes> Ok, I'm not tied to singletons...
<jgarnett> Is there anyway we can make the WFS/WMS request/response classes thake configuration as a parameter?
<groldan> actually, I think the correct think should be having the config hierarchy parent as an application variable rather than a singleton...
<jgarnett> Afraid I am not being very articulate today: what I am really after is a way to let the user try out their configuration before hitting the big save button and inflicting it on everyone
<cholmes> Oh, ok, I see.
<groldan> by that way, you'll be able to have more than one geoserver instance sharing jars
<jgarnett> Similar situtations arise when people ask to have security issues addressed by a wms/wfs. Out of scope for us <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<jgarnett> does "Application Variable" mean something in j2ee land that I am not picking up on?
<groldan> it's just a variable accesible for the whole webapp context
<groldan> throw Servlet.getServletContext().getAttribute(name)
<groldan> (or something like that)
<jgarnett> thanks: I hate designing when I don't know the field that well
<groldan> like in jsps, you have page, request, session and application scopes for holding objects
<cholmes> We should see how the tomcat manager handles the issue of 'the big save button', if they do at all...
<jgarnett> Good call chris: stealing a working design, always a great idea
<jgarnett> Okay so we are making a few decisions here:
<TheSteveMonkey> you might want to look at oscache for reloading things stored in different contexts in a nice manner
<jgarnett> - we do need to separate out configuration
<jgarnett> - application variables rather than singleton
<cholmes> Thanks TheSteveMonkey, I'll look into it.
<TheSteveMonkey> I am just happy there is finally a way for me to help out with geotools
<groldan> by that way, hitting the big save button should be a matter of changing that reference, if you're working with a copy of the config object
<groldan> say, you start the changing config session, stores a clone of the current config in session scope rather than in application scope, make changes on the copy, and changes the app reference...
<groldan> (and the lot of things I'm sure I'm missing...)
<groldan> the only problem I can figure out right now is about DB connections.. should we duplicate them when making the config's clone?
<groldan> I don't think so although...
<jgarnett> I don't think we can duplicate the DB connections <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/> The DataStore's tend to save locking tables and other fun things <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<groldan> it's work for the connection pool, not for the config stuff..
<groldan> are that info stored in a per connection basis?
<jgarnett> Question: when changing configuration are we going to have a level saftey? Or will we be changing the live configuration that everyone is using?
<groldan> I thought we were talking of a safe way...
<jgarnett> DataStore keeps a connection Pool and whatever other info is needed (in memoryfeature lock table)
<jgarnett> Okay so we are going to try and set up a safe way?
<cholmes> Do we need to set that up right away? Perhaps that might be something to do if you have time to get to it.
<groldan> ok I see, just that I thought locking info was stores just in the DB itself (for postgis). Is that like some kind of inprocess locking?
<groldan> (excuse my ignorance)
<jgarnett> groldan: yes it is <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/sad.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<jgarnett> chris: I am trying to figure out what we need to set up right away
<cholmes> Yeah, I don't know enough to say, I've never attempted anything like it.
<jgarnett> I agree chris, we both have not attempted something like this
<cholmes> Well, in that case let's just atart with the basics, what we need right away, and iterate from there.
<TheSteveMonkey> seems awfully ambitios to allow for a "temp" configuration
<cholmes> So I'd say leave out the safty level out for now, as I don't see it being very necessary.
<jgarnett> Well should we cut that out then?
<jgarnett> If we are always working against the live configuration we can even leave the singleton issue alone
<cholmes> If users start clamoring for it we can put it in. But honestly I think people are going to be pretty psyched with <em>any</em> sort of config.
<TheSteveMonkey> I would think you would want to show that you coudl get teh web forms to actually change things and restart teh server first
<jgarnett> Do we need to restart the server?
<TheSteveMonkey> sorry the webapp
<jgarnett> I was thinking we would be changing the configuration of the web app, and then when we were happy we would ask it to save it's configuration out as xml files
<TheSteveMonkey> I would start by just changing the config and getting the changes to apply
<TheSteveMonkey> once that works you can export the congfig to xml
<groldan> I agree... may be just to be sure things work, writing first, then firing the config reading process again...
<groldan> I mean, to be sue the next time the webapp starts, things are as you expect
<groldan> (sue --> sure)
<cholmes> So it would more or less be persisting with every change then?
<groldan> anyway, throwing a friendly exception if a user makes a request while the startup process is not finished is in my wish list.
<cholmes> groldan, what servlet container do you use?
<jgarnett> I don't think so chris, persist when they hit a big save button
<groldan> I think jody means, persistent for the current instance, really persistent whe you press SAVE
<groldan> (tomcat and websphere)
<cholmes> In tomcat I've never really encountered exceptions if the user makes a request during start up.
<groldan> but not used geoserver under websphere due to JDK 1.3
<cholmes> Unless the server is not set up right.
<jgarnett> I was thinking about a big save button that was going to write out the xml files
<cholmes> For me it the request just takes longer, waits until the start up is done.
<groldan> actually I get a servlet exception if I make a request while still setting up datastores, for example.
<groldan> we have no a flag or something that tells if the confing is done (I think)
<cholmes> Interesting. I'm not against it, I've just never really seen it so it's not really on my wish list (and thus not on my todo list either <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/wink.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<TheSteveMonkey> struts has ways of mapping exceptions to different pages
<groldan> can you set the content-type by that way too?
<groldan> I need to set a content type of application/og.exception.blahblah (something like that)
<jgarnett> So the quick thing to do would be to make a user interface for global config and give these ideas a whirl. Chris can make the call about STRUTs based on GLP issues?
<cholmes> Yeah, go with STRUTs, we can figure out the license issues later.
<TheSteveMonkey> groldan, you mean different excpetions get different pages based upon the class that threw the exception
<cholmes> If it becomes a really big deal we can change to an apache license.
<groldan> more or less... it can be based on the user request. In WMS, the user can want the exceptions as images, xml, etc
<cholmes> Rob already had struts in since early versions of geoserver, so it should be fine. Rob if you're reading this and have issues with struts email me.
<groldan> wich is specified thru the EXCEPTIONS request parameter
<jgarnett> chris: I suppose we better start reading about struts then...
<TheSteveMonkey> I am not sure
<TheSteveMonkey> I reccomend teh husted book for in depth and teh spielman book for the 30k foot view
<groldan> don't worry, I have to manage it internally anyway <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<jgarnett> so we covered a fair bit: what we need to config, where it needs to be stored, and how we need to write it...
<TheSteveMonkey> I also reccomend setting up the struts example apps and using them to help you out
<jgarnett> Here is the hard one: what do we want it to look like?
<-- jmacgill has quit (niven.freenode.net irc.freenode.net)
<jgarnett> As in does anyone have an user interface design ideas?
--> jmacgill (~firstname.lastname@example.org) has joined #geotools
<cholmes> I'd say we should check out other server apps with web admin interfaces. tomcat and? Do we know others? Ones that people like?
<groldan> I'll send some print screens to get some ideas if you want
<TheSteveMonkey> the sunj2ee server has one as well...free to academics
<jgarnett> That would be great
<jgarnett> Anything to get started on.
<cholmes> Could be good to send an email to geoserver-devel, asking for feedback on web admin interfaces that people like.
<groldan> one thing: get rid of applets, or be sure they work on every JRE
<cholmes> I don't think applets should be used...
<jgarnett> I am hoping to use the wms instead...
<groldan> ok. A basic DHTML WMS client should be enough.
<cholmes> One more small issue is about automatic generation of DescribeFeatureType responses from FeatureTypes.
<groldan> si there any OGC spec talking about internationalization? or is just the INSPIRE people?
<cholmes> None of the datastores really are as rich as GML...
<cholmes> So all the schema files created from FeatureTypes are going to be less specific than they could be.
<cholmes> I'm wondering if people will have the need to make their schemas more specific...
<jgarnett> How much more specific to schemas get? Are we just missing out on metadata here?
<groldan> cholmes: how much specific they must to be?
<cholmes> I mean one example is minOccurs, maxOccurs, nillable.
<cholmes> In a GML schema you can say that an element has minOccurs=1 but is also nillable.
<cholmes> But postgis only has the concept of null, not of requiring it's presence.
<cholmes> That's kind of a bad example...
<groldan> I see the need for nillable, but not really for min/max occurs..., what min/max occurs mean after all?
<cholmes> But with an XML schema you can really limit most anything, like you could say the only possible values for the 'type' field are 'jim', 'bob', and 'alex'.
<cholmes> But there's no way to really say that in a database, and certainly no way in a shapefile.
<cholmes> min/max occurs is the number of times it can occur in the xml.
<jgarnett> So we still need to keep a bit of xml configuration around, the autogenerate can start us off though
<cholmes> More or less if minOccurs = 0 it is not mandatory, if it is 1 then it is.
<cholmes> Or perhaps we could just have the validation engine take care of this?
<cholmes> Perhaps we could autogenerate <em>with</em> the validation engine?
<groldan> I see, thanks
<cholmes> Yeah jody, that's probably the way to go.
<groldan> but that can't be accomplished by the mandatory attribute in the feature type config? currently we have an <attributes/> element...
<jgarnett> I did not think we were using the xml schema at the moment
<jgarnett> Just accepting the gml on faith
<jgarnett> Actually I have one more bit of biz for us to take care of, do you mind if we return to this in a second?
<cholmes> Yeah groldan, that's why it's a bad example. But the mandatory attribute in featureType config is definitely a hack.
<jgarnett> Okay the other fun thing is that we are going to keep a fairly brisk timeline, chris leaves late January, I have a deadline Jan 28th. I am thinking I better have a draft design document for us this week, which we can finalize next week.
<cholmes> Yeah, we aren't using the xml schema at the moment, but it would be nice to though.
<cholmes> Yeah, would be good to have a draft document.
<jgarnett> What is stopping us from using the schema chris?
<groldan> I yhink that's the kind of stuff a user should want to configure, chris
<cholmes> a gml schema reader.
<jgarnett> that would stop us wouldn't it
<cholmes> In an ideal world we have automatic generation of the initial GML schema, the user could then modify it directly, and then the GML schema reader would serve as the FeatureType, do all the validation...
<jgarnett> Are user's going to complain if we throw GML schema at them and ask them to make sense of it?
<cholmes> I mean, less so than now, right now we require <em>everyone</em> to write their own gml schema.
<cholmes> So we make a lot of people happier with automatic schema generation, as they probably only care enough to get things working.
<jgarnett> (back in a little bit)
<cholmes> groldan, is it getting late for you? Should we try to wrap up soon?
<groldan> sure, that's why i think actually the config is well addressed, you configure in a simple manner what attributes you want yo show and wich of them are mandatory, a FeatureType object is generated and maintained, and the schema generation engine can just use it...
<groldan> yeah chris, it is getting a bit late, and I'm going to watch ER in a few minutes <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<cholmes> There is one problem with that groldan right now though.
<cholmes> The mandatory thing doesn't work as nicely, since geotools schemas don't have the concept of mandatory.
<cholmes> I haven't yet implemented that functionality, because of that, and I think I may just hack it in for now.
<cholmes> Like by not using the FeatureType object, since it can't yet handle a 'mandatory' attribute.
<groldan> yeah, right... but you allways can wrap it.. (just thinking, not that I like having all wrapped)
<groldan> the thing if ti makes sense for the geotools api
<cholmes> That would be an interesting approach...I'll think about it, I need to implement it soon to pass all cite tests.
<groldan> if not, we must to address it at geoserver level
<cholmes> Yeah, it should be done somehow in geotools, I've just never really figured out a great way to address it.
<cholmes> Because it's really a question of the minOccurs/maxOccurs thing, as it really is minOccurs=1.
<cholmes> But maxOccurs should also be able to eqaul like 5.
<groldan> but since datastore have no way of knowing when an attribute is mandatory (may be except for fields of a primary key)
<groldan> may be the right place is just geoserver
<cholmes> I made a multiAttributeType awhile back, that you could set with different minOccurs/maxOccurs, but am not sure if we want that concept in the AttributeType api.
<cholmes> Yeah, that's the problem. The one option is to make 'nillable' mean mandatory, but they really are slightly different concepts.
<groldan> I don't understand. a maxOccurs of 5 means that the same property can occur 5 times for a single feature?
<cholmes> It's xml, like if you define a person, and they can have a max of 5 'brother's.
<cholmes> You can also have maxOccurs='unbounded'.
<groldan> that not makes sense to me... I see features as tuples... and if you have nested features.. I don't know
<cholmes> Yeah, I agree with you, it doesn't make much sense.
<cholmes> Unfortunately it's in the spec...
<cholmes> We actually had to fight in the CITE testing/reference implementation project to not have them test all wfs's for the ability to handle it.
<groldan> so a maxOccurs of 1 is compliant with the spec <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<groldan> ok, I understand it at object concept level
<cholmes> The compromise was that there's this extra button you can click on the test engine to test 'complex features', including one with maxOccurs=3.
<groldan> just that I don't see it in our datastores
<cholmes> Yeah, the thing everyone does is just have maxOccurs as one.
<cholmes> Well, in theory you can have a one to many mapping in a database.
<groldan> but in that case I have the relational field in my featuretype, not the pointed values...
<cholmes> So that a column refers to table that lists as many rows as you'd like.
<groldan> (I repeat, I understand it conceptually)
<groldan> but are you going to update the related table as well?
<cholmes> Yeah, we're on the same page. I agree, it's lame, I don't want to support it, but it is there.
<cholmes> In theory yes. But we compromised out of supporting it, so unless someone really wants to pay us to support complex features we're not going to do it.
<groldan> may be I'm just very tied to relational databases... (and simplicity)
<cholmes> Yeah, it was all Galdos who wanted this, and they basically just wanted to show off how cool gml could be.
<groldan> any experience with object oriented backends?
<cholmes> No, none at all.
<cholmes> You should get going, it is getting quite late for you. Thanks a bunch for showing up though.
<groldan> no problem, I'm missing working on it. may be I can be more active in a month
<groldan> I'll quit for my current job <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<jgarnett> Hey I am back!
<cholmes> You have any questions for groldan? I was just letting him go, as it's getting late in Spain.
<jgarnett> No - just thanks a lot for your help!
<groldan> no worries, and thank you for yours
<groldan> ok, since I'm already sleeping, I'll just put my body on my bed
<jgarnett> And we have answer my main question: what skill set do I need to hire to help me out <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<cholmes> What's the answer? Struts?
<groldan> bye (jody, I think that was some nice words, but did't understand them at all <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<groldan> oh, I understand now. sorry
<-- groldan has quit ("ChatZilla 0.9.47 <span class="error">[Mozilla rv:1.6b/20031117]</span>")
<jgarnett> hi again - people have been interupting me
<jgarnett> Sounds like struts is highly recomended
<cholmes> Yeah, I'll get TOPP to buy me a book as well, so I can be of some help.
<jgarnett> Chris did you want to grab logs for the geoserver site, or do we not care? I at least want to save your list of what we need
<cholmes> Yeah, I think I"ll post the logs on geoserver site.
<jgarnett> and we wanted to send out an email for user interface design recomendations?
<cholmes> Yeah, do you want to do that?
<jgarnett> I will send out the email then.
<jgarnett> (fun trying to plan when we don't know much <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/> )
<jgarnett> QUick question:
<cholmes> So it goes...
<jgarnett> has the wms branch been merged onto the head yet?
<cholmes> Oh yeah, I meant to answer that.
<cholmes> No, it hasn't.
<jgarnett> okay - any plans to do that?
<cholmes> It's on my todo list.
<jgarnett> okay <img class="emoticon" src="https://jira.codehaus.org/images/icons/emoticons/smile.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>
<cholmes> I'd say hopefully by the end of this week, but I've been sliding back on a number of things I want to get done.
<jgarnett> Thanks for setting this up BTW
<cholmes> It's amazing how much random admin stuff takes up my time...I used to be able to code all day long, now I feel I'm lucky if I get 4 hours.
<cholmes> No problem.</li>
CodeHaus Comment From: dzwiers - Time: Wed, 4 Feb 2004 20:16:42 -0600
<p>completed in 1.2.0 alpha</p>