IRC Log from the OpenLayers v3 meeting

<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@…) has joined #openlayers
	aabt (~aabt@…) 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@…) has joined #openlayers
<elemoine>	but am not sure how to address that though
<--	tomkralidis has quit (Changing host)
-->	tomkralidis (~tomkralid@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@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@…) 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@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@…) 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