Thanks for the logs Roald. I put them up here: http://trac.openlayers.org/wiki/Meetings/06/24/2010
(Not sure if anybody else posted them elsewhere already.) Tim On 6/29/10 7:16 PM, Roald de Wit wrote: > > <bartvde> | hi ahocevar and everyone:-) > <elemoine> | hi everyone > <tschaub> | go 3.0 meeting! > <elemoine> |http://trac.openlayers.org/wiki/three > * | strk will be attending meeting, talk about WKT later:) > <tschaub> | rough agenda? 1) additional suggestions not on that wiki > page, 2) who wants to champion what, 3) what do we do when > <ahocevar> | +1 > <elemoine> | ok > <bartvde> | ok > <tschaub> | I was a bit lofty in the original goals I put on that page > | do others have more concrete suggestions that aren't ticketed? > --> | friedi ([email protected]) has joined > #openlayers > | aabt ([email protected]) has > joined #openlayers > <ahocevar> | I think handlers should work globally, and not be > instantiated for each control. > | This will avoid conflicts with multiple controls. > | components should be able to subscribe to handler events. > <elemoine> | I agree that this is an issue > <ahocevar> | Similar to tschaub's feature agent. > --> | tomkralidis > (~tomkra...@cpe0013ce450e14-cm001692413c80.cpe.net.cable.rogers.com) has > joined #openlayers > <elemoine> | but am not sure how to address that though > <-- | tomkralidis has quit (Changing host) > --> | tomkralidis (~tomkra...@osgeo/member/tomkralidis) has joined > #openlayers > <tschaub> | yeah, I like the idea of the map firing all kinds of map > related events > | we seldom (if ever) need to register listeners on other > elements > <bartvde> | tschaub more like the concept of event delegation? > <tschaub> | and I think we can configure a map event dispatcher for > specific stuff like feature related events > <ahocevar> | sounds good. > <vmx> | so a single place to listen to events? > <tschaub> | bartvde: yeah, I think it should be as easy as > map.events.on({click: foo}) > <bartvde> | right > | makes sense > <tschaub> | and people can make other "observables" with the Events > constructor > | if they wanted to > | much as it is now, but with more application events being > fired from map.events > <juliensam> | neat > <tschaub> | with click and doubleclick functionality that is now in the > click handler > <vmx> | this would make it also easier for external libs to attach > their event system to the openlqyers one > <elemoine> | would that address the issue with handlers that Andreas > raised? > * | tschaub scrolls up > <ahocevar> | yes it would. > <tschaub> | yeah, I think so > <ahocevar> | elemoine: e.g. if you take a control as it is now: it > creates handlers. > <pgiraud> | and that would be easier for users to understand > <tschaub> | we want to provide register and registerPriority type > control as well > <ahocevar> | instead, in the future it would listen to map events that > get fired instead of the handler callbacks that are now used. > <tschaub> | (and decide on which is the default) > <elemoine> | ok > <tschaub> | I'm also very interested in streamlining the drag flow > | fewer translations from pixel to map coords > | less chatty with the layers > <ahocevar> | very good point. > <pgiraud> | would we gain in performance ? > <ahocevar> | definitely > <tschaub> | well, fewer lines of code to execute is fewer lines > --> | basilisk ([email protected]) has joined #openlayers > <tschaub> | another thing we've talked about (that could get tested in > 2.10) is OpenLayers.Location > | to replace OpenLayers.LonLat > | Geometry.Point would extend Location > | both would have projection properties > <elemoine> | with information about the projection? > <crschmidt> | crap > | did i mess up a time? > <tschaub> | map.setCener(loc) would do the right thing > * | crschmidt thought meeting was in a little while :/ > <bartvde> | hey chris > <pgiraud> | crschmidt: we just started > <juliensam> | What's the problem with LonLat? > <crschmidt> | juliensam: it's not about lons or lats! > <ahocevar> | juliensam: LonLat can be LatLon (WMS 1.3) > <crschmidt> | it's about xes and yes > <tschaub> | LonLat implies longitude and latitude > <juliensam> | ok thanks > <pgiraud> | many users are lost with this denomination > <crschmidt> | tschaub pointed this out like, 12 hours after we released 2.0 > | and i said 'fuck' > <tschaub> |:) > <crschmidt> | and we've lived with it ever since:) > <juliensam> |:) > <pgiraud> | it's time to get rid of it > <-- | dkobia has quit (Ping timeout: 240 seconds) > <crschmidt> | So, the key thing to me > <elemoine> | but do we need Location*and* Point ? > <crschmidt> | is that I want people to be able to call > map.setCenter(location) > | and if the map is in a projection, but the Location is in > degrees, the map handles it > | all this silly 'setCenter(lonlat.transform())' stuff is > unfriendly > <tschaub> | elemoine: I think the geometry types make sense - whether we > use point for map.setCenter is up for discussion > | location could be lighter weight > <elemoine> | tschaub: yep > <tschaub> | in case people want a build without geometry > | crschmidt: exactly > <juliensam> | Should img coords be a projection then? > <tschaub> | map.setCenter(loc) handles it > | default to wgs84 > <pgiraud> | do the Location class know something about the projection ? > <tschaub> | (loc.projection that is) > <elemoine> | pgiraud: yes > <tschaub> | map.setCenter(new OpenLayers.Location(-180, 90)) > <elemoine> | and it would make transform more user-friendly as well > <tschaub> | that would work if the map is in another projection > <elemoine> | point.transform(destProj) > <bartvde> | but I assume all geometries will get projection info right? > <tschaub> | right > <crschmidt> | so, another key problem > <tschaub> | map.setProjection? > <crschmidt> | is the whole 'map properties like maxExtent' don't actually > have any meaning > <tschaub> | oh yeah > <crschmidt> | the whole base layer disaster > <-- | TheDarkIdiotss has quit (Ping timeout: 240 seconds) > <tschaub> | yeah, we could start with methods like map.setProjection > | and later add base layer type magic where it fits in > | layer groups is the second part of that > <ahocevar> | like e.g. restricting the map extent to that of the base > layer > <crschmidt> | so, do we change the map definitions to actually have 'the > meaning'? > <tschaub> | if others agree, I think it would be simplest to start with > projection& resolution related properties on the map only > <crschmidt> | (And then have them be changable)? > | Okay > | I can cope with that > <ahocevar> | +1 > <bartvde> | +1 > <crschmidt> | It's scary, but that's okay:) > <tschaub> | layers need a way to advertise what they support > <pgiraud> | +1 > <tschaub> | so they could be disabled (e.g.) > <ahocevar> | with wmts and more or less mandatory capabilities, we could > use a concept of layer capabilities library wide > <tschaub> | yeah, would be good to generalize a set of layer capabilities > | we already have many of them > <madair> | the map object needs correct projection and extent always > <ahocevar> | similar to what we now call "layer options" > <tschaub> | and I think we probably all agree it shouldn't take more to > create (for example) a wms layer than it does now > <ahocevar> | definitely. > <bartvde> | sure > <elemoine> | do we want to support multiple baselayers with different > projections? > <bartvde> | are we keeping the concept of baselayers at all? > <tschaub> | crschmidt: any other biggies - seems like transform and > extent/resolution stuff is pretty big > <bartvde> | reprojecting the map should be possible > <ahocevar> | elemoine: I'd prefer to not distinguish between base layers > and overlays, but instead provide convenience methods that apply layer > capabilities to the map. > <tschaub> | bartvde: I think it could be addressed in a different way > (http://trac.openlayers.org/wiki/three/RemoveOverlayBaseLayerDichotomy) > <bartvde> | tschaub: I am all in favour of that proposal! > <tschaub> | being able to say "these four layers are mutually exclusive > in terms of visibility" is nice > | to me (and I admit this is a limited perspective) the case of > toggling layer visibility and having that toggle map projection is of limited > use > | but I know it is widespread > | it could be handled by a "control" or at the application > level though > <bartvde> | right that's what elemoine was doing already > <tschaub> | I'm not sure layer.setVisibility should have it all baked in > * | pgiraud still isn't used to the fact that a baseLayer options > have an higher priority than the map > <elemoine> | bartvde: yes > <crschmidt> | pgiraud: the map options don't have*any* priority, that's > all:) > <tschaub> | pgiraud: me either:) > * | pgiraud likes the idea to remove the baseLayer concept > <crschmidt> | but we want to change that > | so map projection is everything > | geometries know their projections > <tschaub> | map properties rule > <pgiraud> | because it's easier to understand > <crschmidt> | yes > <tschaub> | geometries are smart! > <bartvde> | great > <pgiraud> | ok > <elemoine> | sounds good > * | tschaub likes having noble tenets > <ahocevar> |:-) > | one thought on multiple symbolizers: > <tschaub> | "you can't render a geometry" served us relatively well for > a while > | bring on symbolizers > <ahocevar> | right now our renderers set style attributes. instead, a > renderer just needs to know the max number of symbolizers, clone the whole > svg/vml dom, and all symbologies can be set with css instead of style > properties. > <tschaub> | ahocevar: but the css gets generated runtime? > | the css proposal I suggested a while ago was about supporting > user provided css > <ahocevar> | yeah, that's not cross browser, but possible for all > browsers. > | tschaub: I know, but I found the concept appealing > <tschaub> | yeah > <crschmidt> | styling features with CSS scares me a lot > * | tschaub doesn't know the difference between generating css in > the renderer and applying style properties to nodes > <crschmidt> | i have already seen many many users (even smart ones) be > completley unable to use Rules/Filters > <-- | rkj has quit (Quit: Leaving.) > <msavarese> | newbie with GeoJson questions here. I have a geojson layer > wgs84 on top of a google base map. They don't line up, how do i re-project > the geojson layer. > <ahocevar> | crschmidt: you could avoid style objects and set css > directly. > <crschmidt> | 'set CSS directly'... on what? > <ahocevar> | and the style object and sld readers could create css > runtime. > <tschaub> | afaict, we'd have to parse the css and apply style > properties manually > <ahocevar> | crschmidt: on classes that the rendered representations of > geometries are configured with > <tschaub> | ahocevar: how about we back up to the symbolizer level > | perhaps the css part is an implementation detail to > investigate > | ? > <bartvde> | people should be able to sue css classes should like > externalGraphic > | sue=use > <ahocevar> | I was thinking about a 1:1 relationship between css classes > on the rendered geometries and symbolizers. > * | tschaub loves the idea of supporting user css and doesn't > mean to imply otherwise > <ahocevar> | is that what you meant tschaub? > <elemoine> | last post on the mailing list: "i think i have to use > Filter.Spatial + Rule + Style > | but i can't find the right way to do it!":-) > <tschaub> | elemoine: css is about rules (see stylesheet rules), filters > (selectors) and symbolizers (style blocks) > | the concept is very well tested > <ahocevar> | I have no big picture of how to implement it yet, but we > should investigate it. > <tschaub> | the hurdle is the manual construction of all the required > objects > <ahocevar> | I like the idea. > <tschaub> | css is a serialization format > | rules, filters, and symbolizers are the objects we deal with > <elemoine> | tschaub: have you said we'd need to parse css and create > style objects? > * | ahocevar would not think so > <tschaub> | we could provide a css parser that created rules, filters, > and symbolizers > <crschmidt> | okay, so this is tarting to make more sense to me, I think: > Basically, we could use CSS as the way that users*create* Style/Filter/Rule > objects > <ahocevar> | on the contrary. > | if you have css, you don't need style objects at all. > <tschaub> | crschmidt: yes it could be a format we read > <crschmidt> | ahocevar seems to be saying "Styles/Filters/Objects would > simply create CSS, and that would apply to the SVG DOM Elements" > <tschaub> | ahocevar: only if we have the same dom structure on all > browsers, right? > <crschmidt> | (my answer to that is "What about renderer.canvas") > | (Which has no DOM) > <tschaub> | yes, canvas > | in any case, it's a bit of an implementation detail > <crschmidt> | yeah > <ahocevar> | good point. same dom structure, and a dom, are required for > this approach. > | maybe a showstopper. > <tschaub> | if a specific renderer can be made to work, great > | the point is we can also parse css and create the objects we > need > <crschmidt> | I do think that we should support the following two use > cases: > | 1. The SLD-style Use case, where users are styling features > based on programatic rules > | 2. The KML-style use case, where users are specifically > styling a feature with a given style > | (KML has many ways of doing it, but think of the way that > something like google my maps does it -- where users are generating style > data for each feature) > * | tschaub thinks the two can be merged > <ahocevar> | which, in the html world, is like css (with selectors) and > style properties (on dom elements) > <bartvde> | crschmidt but SLD can also do 2) > <crschmidt> | ahocevar: yes. > <tschaub> | sld is a serialization format > | css is a serialization format > <crschmidt> | Anyway, we're getting stuck in the weeds, I'm sorry. I think > this probably deserves a longer conversation on the list/ wiki page > | But it's not a*core* problem of 3.0 > | (It's something we should fix, but not the biggest change > needed) > <tschaub> | yeah, I think we all generally see the same thing > | make it convenient to style > <crschmidt> | yes > <ahocevar> | agreed > <pgiraud> | make it easy for users > <bartvde> | +1 > <tschaub> | but remember, functionality first, convenience second:) > | baking convenience in too low will screw us > <crschmidt> | mm > | sure. > | Okay, so: > | 1. Maps are the leaders of all. They have the projetion > properties, and you can reproject maps > | 2. Layers advertise their ability to render in a projection. > If they can't render in one, they turn off or something > | 3. LonLat is a shit name. .Location() is the future, and it > is smart. Geometry comes from Location, and is also smart. > <tschaub> | (or burst into flames) > <crschmidt> | 4. Baselayers are a crappy concept. Mutually exclusive > visibility is the way of the future. Layer groups is a potential name for > this type of thing > <bartvde> | Good summary crschmidt > <elemoine> | yep, thanks for that > <tschaub> | reduce the path length of hot code > <elemoine> | tschaub: moveTo? > <tschaub> | sure > <crschmidt> | 5. Things which are called many times (which we now > know/can examine) should be miproved performance wide > | wise* > <bartvde> | will we be keeping things like getPagePosition, addClass, > removeClass etc.? > <tschaub> | 6. pull out as much core stuff as we think might be > duplicated elsewhere > | and provide adapters given time > <crschmidt> | mm > <tschaub> | crschmidt: it's only an organizational thing > <crschmidt> | I don't want OpenLayers to depend on jQuery/Ext/etc. > <tschaub> | when I say pull out > | yes, obviously > <crschmidt> | But if we want to pull out, and create an 'ol-adapter' stuff > <tschaub> | it won't depend on anything > <crschmidt> | that would be the equivilant > | that is fine > <tschaub> | but, in the case that you have another lib > | we don't make the client download duplicated code > <elemoine> | does it mean we'd keep our own addClass etc. implementations? > <tschaub> | elemoine: yes, we need our own > <crschmidt> | tschaub: Right, I think we're in violent agreement > <tschaub> | but they should be organized in a way that they can be > excluded > <pgiraud> | maybe take it from a permissive licensed library ? > <tschaub> | crschmidt: YES! > <crschmidt> | tschaub: So long as you can use OpenLayers in a way that if > every other javascript framework on the planet disappeared tomorrow > | tschaub: We would be able to just pull things from SVN and > have OL still run > <tschaub> | exactly > --> | rduif ([email protected]) has joined > #openlayers > <crschmidt> | that is what matters to me. > <tschaub> | for sure > <crschmidt> | Okay, Great. > <vmx> | +1 > <crschmidt> | And I'd love to not have to duplicate that code for people > using the Better Frameworks:) > * | tschaub feels the same burn from Prototype as others > <bartvde> | and the same applies for the Ajax part? Create adapters? > <tschaub> | yeah, just refactor what we have first > | improve it if we can > <ahocevar> | speaking of "pulling out": to keep the library small if > customized, we can also pull out geometry operations (geotools/geos like > stuff). > <tschaub> | with what we learn from elsewhere > <crschmidt> | some things we can throw away > <tschaub> | ahocevar: yeah, we could have a geom ops "module" > <ahocevar> | tschaub: sounds great. > <tschaub> | that does beg the question > | brought up before putting in intersects > | about extending geometry > <ahocevar> | that's why I brought it up again:-) > <tschaub> |:) > <vmx> | is there already an idea how those adapters look like? > specified function signatures (like interfaces)? > <crschmidt> | vmx: no > <tschaub> | OpenLayers.Element.hasClass just delegates > | the adapter decides to where > <bartvde> | right but OpenLayers.Util.PagePosition should come to > OpenLayers.Element then > <elemoine> | bartvde: right > <tschaub> | the adapter could provide PagePosition in its entirety > | if it was available from elsewhere > | casting to OpenLayers.Pixel > <bartvde> | sure that's what I am doing right now but overriding the > util function > <tschaub> | right > <bartvde> | what do we with visual stuff, outside of the core library? > | or inside? > <tschaub> | well, map viewport is ours > <elemoine> | bartvde: layerswitcher for example? > <tschaub> | all layer containers are in that > <bartvde> | sure but I mean buttons and layerswithcer > <tschaub> | we should provide a nice small set of widgets > <elemoine> | I think it should stay in core > <tschaub> | layerswitcher et al. > <elemoine> | tschaub: right > <tschaub> | yeah, perhaps named differently > <elemoine> | to make it easy to people > --- | strk is now known as strk_away > <tschaub> | or named the same - but we should distinguish controls and > widgets > | wait, that doesn't read well > | in any case, I think we agree here too > <crschmidt> | We do need to improve the ability for people to write their > own widgety things (which I think we can do, and will do) > <tschaub> | the navigation history control maintains state stack and > allows changing state > | a set of buttons lets you trigger the control > <crschmidt> | Ideally, we want to make something like GeoExt have almost > no openlaeyers interaction code > | just some event.register > |:) > * | elemoine would like to isolate browser dependent code, to be > able to use OpenLayers is server-side js environment > <tschaub> | right > | ui module > <vmx> | crschmidt: +1 > <bartvde> | are we tackling mobile support in 3.0? > <tschaub> | yes! > | or at least facilitating it > * | tschaub should have qualified that first > <bartvde> | I knew that answer tschaub:) > <crschmidt> | haha > | Is there anything hard about mobile now? > <tschaub> | browser event names > <crschmidt> | Like, it seems to me that there are already at least 4 > people who have written iPhone touch supporting controls > <tschaub> | yeah, it is awkward though > <crschmidt> | I would assume at least one of them works > |:) > | Okay > | So we'll work to improve that > <tschaub> | would be nice to sub in an environment > <crschmidt> | need more words > <tschaub> | default to the trad browser environment > | allow others to easily wire together a custom environment > <crschmidt> | hm > | I'm still not getting it > * | tschaub wants to browse an OpenLayers map on a melodica > <crschmidt> | But maybe that's okay. > | the musical instrument? > <tschaub> | I should be able to swap out the environment with one that > wires the native blow event to the pan control > <crschmidt> | Gotcha > | But isn't that what a replacement for the NavigationControl > does? > <tschaub> | or rather, to the map drag event > <crschmidt> | I mean, the NavControl really isn't that complex > <tschaub> | sorry, then the pandrag control relies on map drag > <crschmidt> | Or is there too much math at a lower level somewhere? > | so, it feels to me like the map has the key things you would > 'hook up' your melodica buttons to > | and the DragPan control just gets thrown away > <tschaub> | yeah, its the native events that I want to wire up > <crschmidt> | I don't think that we can generalize above the level of the > map for multiple environments > <ahocevar> | Let's call the connection point between events (blow, touch) > and handlers "sensors". > | you can configure a handler to use different sensors, > depending on the platform. > <crschmidt> | Really? > <ahocevar> | (or something like that) > --> | pwr (d9ab8...@gateway/web/freenode/ip.217.171.129.68) has > joined #openlayers > <crschmidt> | I wouldn't expect them to be similar enough, is all. > <tschaub> | yeah, we need to draw a table > <ahocevar> | maybe, yeah. > <tschaub> | and sit around it > <crschmidt> | But sure, the theory there is fine > | yeah > <tschaub> | and then draw a chalkboard > <crschmidt> | hehe > <tschaub> | and then draw on it > <crschmidt> | We have f2f time to work out some of this stuff > | so long as we don't use all the f2f time to chalk things out > and not write any code:) > <tschaub> | f2f? > | ah > | yes > <bartvde> | face 2 face > * | tschaub thought some new company was dropping bags of money > on us > <tschaub> | wishful thinking:) > * | ahocevar ducks > <crschmidt> | f2f is clearly c2c plus... 4 or something > <bartvde> | you saw the sencha input of 14 million ? > <crschmidt> | 5? no, 4 > | SENCHA > | sorry > | Feeling a bit slaphappy > <pgiraud> | lol > <crschmidt> | Okya, so we have some serious directoins > | We also have a*lot* of things that are minor and easy to fix > * | tschaub has a plane to catch > <crschmidt> | removing depracated functions, etc. > | do you have 5 minutes? > | The questoin I want to ask is: What should we do*right now* > if we have free time that we want to spend on OL 3.0? > | Is an SVN branch good? Should we branch to github and all > work there for the time being? > * | ahocevar is fine with both options > <bartvde> | for me an svn branch would work, I am not even on github > yet:) > <-- | rduif has quit (Ping timeout: 265 seconds) > <tschaub> | yes, on to agenda item 2.5 > | yup > | fork and delete > * | tschaub likes the idea of playing on github > <elemoine> | me too > * | vmx would prefer github > | tschaub registered the openlayers account > <crschmidt> | bartvde: I'm happy to help teach git > <bartvde> | no problem I'll learn it:) > <crschmidt> | tschaub: Can you fork trunk to git for now in some way? > * | pgiraud will be taught git by elemoine > <tschaub> | yes > <crschmidt> | tschaub: and then we can play there? > | great > <tschaub> | later tonight at best > <crschmidt> | no problem > | not a huge rush > | i'm sure none of us have a ton of time > | just want to not put everything off until 3 months from now > * | tschaub doesn't want the enthusiasm to drop though > <tschaub> | agreed > <bartvde> | do we still think 2.10 will be viable? Who will be release > manager of that? > <tschaub> | sorry for appearing to suggest otherwise > <crschmidt> | I'm happy to push out a 2.10 > | hell, I'm happy to even continue pushing out bugfixes that > are submitted going forward > | and do 2.10.1, 2.10.2 etc. > <elemoine> | I can be release manager > <crschmidt> | I'm just not going to write all the code for it > <elemoine> | but in august > <crschmidt> | btw, docs.openlayers.org and dev.openlayers.org are both > running on an osgeo server now > | one that other people can get a login to > <bartvde> | great > <elemoine> | july is mostly vac for me > <tschaub> | anyone want to avoid the bad luck of 2.10 and stick with > 2.9.x? > <crschmidt> | heh > | i'm not against that > <pgiraud> | maybe something to think about for 3.0 is the auto generated > documentation > <crschmidt> | do we pull things like WMTS into 2.9.x? > <tschaub> | we would look cool > <bartvde> | "still amazed by Italy's kick-out of the world cup" > <tschaub> | sure > <pgiraud> | elemoine thinks that it's not really 3.0 relative > <crschmidt> | okay, so .x doesn't just mean 'no new features' > * | tschaub is still freaked out by the 91 minute us goal > <dwins> | i have a git-svn clone of OL ready to go if you want. it > doesn't have sandboxes though > <elemoine> | I'm not a big fan of adding new features in a point release > | why not do 2.10 for that > <tschaub> | oh, just because I'm being silly > <crschmidt> | elemoine: 2.10 is just ugly;) > <tschaub> | I like the idea of 2.8, 2.9, 3.0 > <elemoine> | that? > <crschmidt> | look at tilecache: It hit 2.10 and never went any further! > <tschaub> | we look cooler in retrospect > <stvn> | how much work is adding WMTS to 2.*? > <crschmidt> | stvn: It's already in trunk. > | It's just a question of what we release it as > <-- | friedi ([email protected]) has left > #openlayers > <tschaub> | additional stuff needs review (and a bit more work) > <stvn> | I'd like to see WMTS in 2.* then and not have to wait for > 3.* to get stable (just a user perspective) > <elemoine> | 2.10 looks good too, as the final 2.x release > <stvn> |:) > <bartvde> | sure 2.10 is fine by me > <tschaub> | dwins: sounds good - we don't want the sandbox structure > anyway - we'll use git branches > <bartvde> | I am not superstitious;-) > <crschmidt> | Anyway, I'm happy to take back over any release stuff going > forward for 2.next+ > <bartvde> | call it 2.final:) > <tschaub> | oh, I had an agenda item 3.5 as well > <dwins> | tschaub:http://github.com/geonode/openlayers - fork away > <crschmidt> | but my method for managing tickets that say 'Review' is > "Better luck next time":) > <tschaub> | crschmidt: any quick update on website "infrastructure"? > | we can have a different meeting on it > | just wanted to get a sense of the current state > <crschmidt> | tschaub: plan is to mvoe everything to osgeo > <tschaub> | website included? > <crschmidt> | We have new fast servers there now > | yes > | and then anyone can have login access to the server > | just need to be added to the group > <tschaub> | sounds good > <crschmidt> | svn, trac, mailing list, and all the sub-sites > | sub-sites are*already* moved > | I almost moved ol.org too > | but forgot about/pipermail/ > <tschaub> | do you need (and could you use) help? > <crschmidt> | nah > | i'm in good shape > <tschaub> | ok, my plane is actually boarding now > <crschmidt> | okay > | cool, tschaub > | thanks for everything > <bartvde> | have a good flight > <tschaub> | I'll catch up on the logs later > | good meeting all > <crschmidt> | tell us when we have a git repo:) > <tschaub> | will do > <elemoine> | it's going to be wild > |:-) > <-- | tschaub has quit (Quit: tschaub) > <crschmidt> | so, I feel like we have a bunch of topics > | we have a pretty solid direction > | and we have a lot of little tasks that people can help with > | can someone take my points earlier (and followups in the > past 20 minutes) and send email to the list? > | and then we can spawn threads for contentious topics > <bartvde> | I can try (though Netherlands is playing soon:-) ) > <-- | VMESDO has quit (Remote host closed the connection) > <elemoine> | I won't be able to do it today and tomorrow > | but I'm happy with bartvde picking it up > | s/but/so > <juliensam> | do you include tschaub last point in that ? : 6. pull out > as much core stuff as we think might be duplicated elsewhere > <elemoine> | except it's not pull out > | it's the adapter idea, with our own impl > | thank all > | bye > <bartvde> | thanks > | bye -- Tim Schaub OpenGeo - http://opengeo.org Expert service straight from the developers. _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
