[OpenLayers-Dev] OpenLayers 3.0 IRC Meeting summary
Tim Schaub
tschaub at opengeo.org
Wed Jun 30 17:24:01 EDT 2010
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 (~friedi at pd95bc5db.dip0.t-ipconnect.de) has joined #openlayers
> | aabt (~aabt at lns-bzn-51f-81-56-146-207.adsl.proxad.net) 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 (~tomkralid at 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 (~tomkralid at 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 (~basilisk at 202.3.77.209) 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 (~richard at a80-127-244-111.mobile.xs4all.nl) 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 (d9ab8144 at 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 (~friedi at pd95bc5db.dip0.t-ipconnect.de) 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.
More information about the Dev
mailing list