This page last changed on Dec 11, 2013 by jive.

Conversation between Chris Holmes (cholmes) and Gabriel Roldán (rulobilbao):

(apologies if this doesn't format well, I'm just cutting and pasting)

cholmesny: Hey Gabriel!
rulobilbao: hey, sorru for not being responding, I was out of office yesterday
cholmesny: Oh no worries at all. I'm on it.
cholmesny: And I feel like you did say somewhere that you finished the re-org - I think David just missed it.
rulobilbao: quick answer: you're right, I should communicate more frequently the status of changes. I plan to do some docing on the wiky once geoserver.util gets reorganized
rulobilbao: (by now it is more a place where to put things that do not belongs to more specific places)
cholmesny: Sounds good.
rulobilbao: yeah, I announced it on the list and jira
rulobilbao: but it is not finished at all. look: there still need to figure out the better to do with config
rulobilbao: I would like to decouple the ui stuff from core
cholmesny: Yeah, I've been thinking in that direction as well...
rulobilbao: yeah, that's because I'm intermitently online
rulobilbao: yeah, right now core depends too much on struts
cholmesny: I think it should be just above core - so perhaps the other services could depend on ui (or whatever we call it).
cholmesny: But yeah, core depending on struts is not a good thing.
cholmesny: I was super against it when jody and them were doing their changes.
cholmesny: For some reason they sorta talked me into it when I was up at refractions.
cholmesny: But yeah, no struts stuff should be in core.
cholmesny: Wait, hold on - how is the ui stuff coupled to core?
rulobilbao: right. So there is a bunch of things to do in that directions, some of them are as subtasks of the reorg. jira task, like decoupling core from the servlet interfaces as a first step
cholmesny: global is the core package right?
rulobilbao: yes
cholmesny: I believe it is totally decoupled from the ui.
cholmesny: This was a big design requirement of mine.
cholmesny: global as dto - data transfer objects.
rulobilbao: but we need struts to setup geoserver, right?
cholmesny: For start up - but that's the only thing.
cholmesny: And I only realized that like a couple of months ago.
cholmesny: Beyond that I'm pretty sure it is totally decoupled.
cholmesny: The config package mirrors the dto's
cholmesny: And the struts stuff only operates on those.
cholmesny: Until apply or save is hit, then it turns config into dto's, and passes them to global.
rulobilbao: yeah, I guess so too, and I'm pretty sure it should be a pretty straightforward change
rulobilbao: so that's the challenge to 1.3.0. How do you feel about my idea of separating modules in their own "projects" after that? (like with maven)
cholmesny: Cool. Yeah, Jody still brings about how I made them do all these extra layers for the ui. And it is a bit much, for sure. But it did keep things seperate - indeed I was shocked to see that geoserver relied on struts for start up, since I thought it was totally decoupled.
cholmesny: Yeah, that's the next logical step to the plug-in architecture, no?
rulobilbao: yeah, I would start with another thing though, before being ready for that separation:
rulobilbao: that is changing the hinheritance based service architecture, which is a bit messy (the stuff with AbstractService as root), to a chain of responsability, favoring composition and dynamic factory lookup
cholmesny: Yeah, that sounds good.
cholmesny: Have you looked at Spring at all?
cholmesny: I think that would be a good thing to research, make use of some of their stuff, as I've heard nothing but good things, and it's super well designed so you can pick and choose what you want.
cholmesny: We also may check out cocoon a bit - design with them in mind, use some of their widgets as well. I think they have some good stuff for configuration.
rulobilbao: Actually I was looking at a similar library from apache, let me look for an url
cholmesny: I think for 2.0 we should take some time to review the other open source projects out there and make use of as many good ones as we can.
cholmesny: The bitch is probably going to be the UI, as struts kinda sucks, but I don't know anything better.
rulobilbao: I would be pretty against cocoon, and propose basing the config stuff on Java Server Faces, which is a standard, can coexist with struts, and allows migration from struts to JSF
rulobilbao: JSF is the successor of struts, and has a lot more of functionality
rulobilbao: and is a JSR
cholmesny: By config stuff I don't mean ui - I mean the persisting of configuration...
cholmesny: Like going from global objects -> xml files.
rulobilbao: mmm... I would like to evaluate some apache stuff too
cholmesny: I would also like to be able to persist configurations to a database.
cholmesny: Ok. I'll try to get Jeroen to kick you some money to do a bunch of research, and even write it up and present it to the community.
rulobilbao: yeah, xml files, db, ldap, we should take the time to find already done good things rather than reinventing the wheel
cholmesny: Exactly - many people have solved this problem. We should just define our objects, and let some libraries worry about the persistance.
rulobilbao: you do mentioned something about sld files as the configuration for wms layers itself, right?
cholmesny: (also we may be talking about the same configuration stuff when I say cocoon and you say apache - it's a seperate package that came out of cocoon I think).
rulobilbao: yeah, I guess so, but to be more confident I need to investigate a bit more, since don't really have experience with that stuff
cholmesny: Um - no more than we already do - sld files are the file format we read for our named layers.
rulobilbao: I was thinking in something similar but more directed to a web map context document. That way you can reuse styles in different layers, and will allow to declare nested layers as the spec says
rulobilbao: it could be a good standard configuration format for a wms too...
cholmesny: Oh yeah, styles in different layers would be good. Though I was actually just thinking that we should automatically figure out which styles will work with which layers.
cholmesny: I mean, we already can figure out what the propertyNames needed are from a style.
cholmesny: I think we just need to extend that, and can figure out which layers will be able to render which styles.
rulobilbao: yeah, but I would like a bit more of control at user's side
cholmesny: Though yeah, we should try to make the file format based on a web map context document. Push it as a common format for sharing with mapserver.
cholmesny: True, I agree with that - a hybrid would be ideal - users can only select ones that actually work...
rulobilbao: I mean, even if you have a sld for rendering highways and it can be applied to the countries polygons, don't think it should have too much sense
cholmesny: true - I was just thinking it would be better than what we've currently got, without having to do a bunch more ui work.
rulobilbao: I agree it would be easier, but I think too that we will need a good ui if we want more acceptance
cholmesny: For sure - I'm a huge fan of the ui.
rulobilbao: I have some plans for that, just need the time/resources to do it. basically:
rulobilbao: a ui should be able of presenting your layer hierarchy as a nice tree, be able of designing styles with at least enough complexity for specifiying filters and symbology, and be able of previewing resulting maps
rulobilbao: with all that stuff, it would be easy to have a wizzard to create web mapping applications ready to use
rulobilbao: that's because I'm impressed about using/contributing to mapbuilder for that goal, since it is the best project I have seen about W*S lite clients
cholmesny: Yeah, I've always dreamed of similar things (well, I never thought of the tree, just designing styles and previewing maps).
cholmesny: Yeah, I was super impressed by it too. I keep meaning to send them a congratulatory note on the great work.
cholmesny: Also, if we are going to include it in geoserver we should link to it from the main welcome page - it's far too hidden at the moment.
cholmesny: I am a bit hesitant to include, as it is some extra bulk.
rulobilbao: yeah. I notices you were worried about size increase. I agree, but...
cholmesny: But perhaps we just should - better to get interest in it going, and then split out when we have the modular design of opensdi
rulobilbao: what would be nice is to have separate downloads with nice demos
cholmesny: Yeah, I'm also letting the WCS guys play, which I was against before.
cholmesny: Agreed - hopefully if dblasby comes through with the geoserver_home stuff it'll make it super easy to download demos.
cholmesny: You would just change your gs_home to the directory of the download...
rulobilbao: ahá, that would be great, since with the sld getmap stuff it is time of developing some nice interacting demos
rulobilbao: (though still need to solve the geometry filter bug in sld parsing)
cholmesny: I know the problem - I just didn't have time to fix it...
rulobilbao: nor me
cholmesny: It shouldn't take more than 10 minutes...just need to change the names it matches against for the types of geometrys, get rid of the gml prefixes.
rulobilbao: ok, I'm really anxious to have all this in place, since I want to do some profiling too, I'm pretty sure there are a couple of things to do about performance
cholmesny: TOPP is interested in the same issues, so hopefully he can help out getting some of this stuff done.
cholmesny: While you're doing profiling David should have time to make up some really nice documentation and howtos...
rulobilbao: yeah, it was a huge gain having david aboard!
cholmesny: Yeah, he's only going to get better, I'm sure.
rulobilbao: hey, I really have to go, need to send a fax to Jeroen an fix some problems at office, it was nice to meet you
rulobilbao: how is going there?
rulobilbao: it seems we're more in sync with time zone now
cholmesny: Going well. Taking my time getting set up, not really gearing up to do work for awhile - need to figure out place to live and visa and all of that.
cholmesny: It's true - we're probably only a few hours off now.
cholmesny: Though I'm super far off from dblasby now, which is unfortunate.
cholmesny: Ok, get going, thanks a ton for taking the time to chat, sounds like good things are coming.
cholmesny: Oh yeah, other thing to check out if you have time, if you didn't before:
rulobilbao: yeah, hope it will be a nice year
rulobilbao: good bye and be lucky (I'll take a look at that)
cholmesny: They've done a ton of badass work. If possible it might be cool to try to them some opensdi funding to roll the ideas and work directly into it.
cholmesny: Cool, take care.
rulobilbao: ah, yeah, I already read it, sounds interesting
rulobilbao: hey, just a question:
rulobilbao: so the featuretype extensions are in trunk, right? how hard it could be to provide complex schemas from a jdbc datastore?
cholmesny: Depends how generically you want to do it...
rulobilbao: postgis
cholmesny: Based on foriegn keys?
rulobilbao: yeah
cholmesny: I don't know databases and foreign keys and how they are designed and all that well.
cholmesny: But I don't think it should be that hard to get a few cases working right.
cholmesny: I mean, the feature model is totally there now.
cholmesny: You just need to figure out how to map it right.
cholmesny: The other possibility that's been kicked around is hibernate - but that's probably too much investement - if you know jdbc and the design of your database well you could probably roll a solution relatively easily.
rulobilbao: ok, I'll try to combine this with the work from Rob Atkinson in gsc branch and come back with some conclusions (may be a working impl)
cholmesny: That would be great.
cholmesny: Oh wait - actually it'll be a bit more of a bitch.
rulobilbao: is it already working for gml?
rulobilbao: ?
cholmesny: Well, actually it depends again on how generic you want to do it.
cholmesny: Sorry, throwing the sco branch in the mix made me remember more issues.
cholmesny: The way the mapping is done when reading a jdbc result set will probably have to be redone.
cholmesny: Sorry, basically I don't know it well enough to say how difficult it will be.
cholmesny: I am not sure if DavidZ got it working yet for gml.
cholmesny: But he's pretty fast, so I imagine he probably did.
rulobilbao: mmmm... would need to play with it, thanks for your feedback
cholmesny: Cool. Do try to write up your feedback - put it on the wiki. This is the problem that advanced people are interested in the most.
rulobilbao: (I guess I will have to ask more things to advanced people... luckily they're pretty open to help)
rulobilbao: ok, see you
cholmesny: later

Document generated by Confluence on May 14, 2014 22:59