Hi all,
The log of the meeting is attached here. Everything should be in there
exactly as it appeared on IRC. I did apply a few tricks to format the
log nicely and I hope I haven't screwed anything up.
Regards, Roald
<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
_______________________________________________
Dev mailing list
[email protected]
http://openlayers.org/mailman/listinfo/dev
