(01:09:43 PM) Crell: So are we starting this meeting or what?
(01:09:47 PM) ***Crell has clients waiting!
(01:09:53 PM) hejrocker: uh its not for 45 more mintues
(01:09:58 PM) Crell: ...
(01:10:02 PM) boombatower: heh
(01:10:02 PM) Crell: I thought it was at 1 my time.
(01:10:19 PM) Crell: ... Wait.  Europe just changed its DST, didn't you.
(01:10:20 PM) hejrocker: i just know when it is my time
(01:10:20 PM) cosmicdreams: :-(
(01:10:29 PM) hejrocker: no
(01:10:32 PM) Crell: hm
(01:10:45 PM) hejrocker: hold
(01:11:16 PM) hejrocker: hm it was 1 your time last time
(01:11:24 PM) hejrocker: but it was 9 my time last time
(01:11:52 PM) Crell: ... Meaning?
(01:11:56 PM) hejrocker: i dont know
(01:12:01 PM) hejrocker: i said 19.00 UTC
(01:12:04 PM) hejrocker: hang on
(01:12:45 PM) hejrocker: well something changed because that is now 20:00 my time
(01:12:51 PM) hejrocker: so i guess ITS TIME TO START
(01:13:03 PM) cosmicdreams: Whoa!
(01:13:17 PM) hejrocker: http://www.timeanddate.com/worldclock/fixedtime.html?month=2&day=28&year=2011&hour=19&min=0&sec=0&p1=0
(01:13:53 PM) webchick [~Adium@drupal.org/user/24967/view] entered the room.
(01:14:07 PM) cosmicdreams: what's on dock for today?
(01:14:09 PM) webchick: YARRRR
(01:14:14 PM) hejrocker: oh god webchick is here
(01:14:16 PM) hejrocker: im leaving
(01:14:38 PM) hejrocker: here is the agenda
(01:14:39 PM) hejrocker: http://groups.drupal.org/node/176264
(01:14:40 PM) Druplicon: http://groups.drupal.org/node/176264 => Configuration Management Initiative - Bi-weekly IRC meetings => 0 comments, 1 IRC mention
(01:14:51 PM) hejrocker: shit wrong node
(01:15:06 PM) hejrocker: HERE IS THE AGENDA
(01:15:07 PM) hejrocker: http://groups.drupal.org/node/179989
(01:15:09 PM) Druplicon: http://groups.drupal.org/node/179989 => Bi-weekly IRC meeting => 0 comments, 1 IRC mention
(01:15:17 PM) fabsor: this would definitely not have happened if we used uuids
(01:15:24 PM) webchick: LOL
(01:15:31 PM) pounard: TROLL spotted
(01:15:41 PM) ***Crell snickers.
(01:15:43 PM) hejrocker: DONT FEED HIM
(01:16:02 PM) hejrocker: So last week we had a code sprint in Copenhagen and 4-5 people showed up, depending on if you count fabsor
(01:16:21 PM) hejrocker: It went really well, and we actually started our first implementations
(01:16:27 PM) hejrocker: Which of course encountered our first roadblocks
(01:17:00 PM) hejrocker: However we are at the point where you can install drupal, get your pre-requisites in place, and install default XML configuration files as needed
(01:17:07 PM) webchick: !
(01:17:40 PM) cosmicdreams: do you have a sample of that XML configuration file?
(01:17:41 PM) hejrocker: letharion started working on the site information screen and on transitioning variable_get()/set() to the new system
(01:17:50 PM) hejrocker: yeah hang oon
(01:18:23 PM) hejrocker: http://drupalcode.org/sandbox/heyrocker/1145636.git/blob/1cecf9059695168e80d7bb89f4ab7d6761e0d0ce:/modules/image/config/image.default_styles.thumbnail.xml
(01:18:47 PM) hejrocker: this is actually missing a couple pieces of data
(01:18:58 PM) hejrocker: they are supposed to be really simple
(01:19:22 PM) Crell: And that round-trips back to a config object with properties, like we discussed in Denver?
(01:19:25 PM) hejrocker: here is another one
(01:19:25 PM) hejrocker: http://drupalcode.org/sandbox/heyrocker/1145636.git/blob/refs/heads/8.x-file-config-letharion:/modules/system/config/core.system.xml
(01:19:28 PM) hejrocker: yes
(01:19:36 PM) cosmicdreams: ah so given the name of the xml file.  The system knows that it is supposed to be used to create the thumbnail image style?
(01:19:50 PM) hejrocker: cosmicdreams, i would actually include the name in the xml, that should be added imo
(01:19:59 PM) ***hejrocker was just noticing that is missing
(01:20:06 PM) hejrocker: image styles are the next thing i wanted to work on
(01:20:26 PM) cosmicdreams: cool, and blocks?
(01:20:29 PM) Crell: Is there a reason you're using property->element name mapping rather than property->attribute value?
(01:20:37 PM) Crell: Blocks are on the table for WSCCI to gut and rewrite anyway, we hope.
(01:21:02 PM) cosmicdreams: Crell: Niiiiice.  creating those in install profiles are a pain when you have multiple themes.
(01:21:10 PM) Crell: Yes
(01:21:10 PM) hejrocker: i thought we agreed that we didnt want attributes
(01:21:23 PM) hejrocker: except for metadata like languages
(01:21:39 PM) webchick: We did. Keep it simple.
(01:22:00 PM) Crell: I mean <property name="site_slogan">value here</property> // or something like that.
(01:22:03 PM) Crell: not to bikeshed, just curious. :-)
(01:22:13 PM) hejrocker: seems like excess complexity
(01:22:19 PM) webchick: One of the detriments to XML is that there are so many frigging ways to represent data, so we went with an all-key approach to minimize that.
(01:22:31 PM) webchick: iirc
(01:22:46 PM) cosmicdreams: hejrocker: in http://drupalcode.org/sandbox/heyrocker/1145636.git/blob/refs/heads/8.x-file-config-letharion:/modules/system/config/core.system.xml why is there a semicolon at the end of </site_mail> ? is that a typo?
(01:22:54 PM) hejrocker: yes
(01:22:58 PM) hejrocker: letharion, are you around?
(01:23:01 PM) cosmicdreams: Ah thank you
(01:23:24 PM) hejrocker: you can see here some of what letharion was doing to implement this http://drupalcode.org/sandbox/heyrocker/1145636.git/commitdiff/6e2a5af3aa8461e1f0d3793af41a3e6ddab8a4af
(01:24:22 PM) hejrocker: naxoc was writing tests at the code sprint
(01:24:24 PM) cosmicdreams: Where are config files stored by default?
(01:24:27 PM) hejrocker: xendk was working on the image styles
(01:24:50 PM) hejrocker: one other was there too
(01:24:56 PM) ***naxoc should work some more on that test
(01:24:58 PM) hejrocker: cosmicdreams, modules provide a default xml file
(01:25:09 PM) hejrocker: which is copied into the live config directory at install
(01:25:23 PM) hejrocker: that system will basically be the functional equivalent of hook_schema() i think
(01:25:45 PM) cosmicdreams: at install is the config represented by code or as a file?
(01:25:50 PM) hejrocker: file
(01:26:01 PM) hejrocker: in a /config directory
(01:26:08 PM) hejrocker: antyhing with *.xml gets installed
(01:26:32 PM) hejrocker: see http://drupalcode.org/sandbox/heyrocker/1145636.git/tree/refs/heads/8.x-file-config-letharion:/modules/system
(01:26:56 PM) cosmicdreams: so if you were working on a site you wanted to have a different config at install you could just put in an overriding xml file into that config directory and the installer would use that config instead of the default?
(01:26:59 PM) Crell: We may want a different extension to avoid conflicts with things like solrconfig.xml, which apachesolr ships.
(01:27:19 PM) cosmicdreams: or would you have to hack the default xml file for site-specific config alterations?
(01:27:20 PM) Crell: Or does it only read out of the config subdir?
(01:27:27 PM) hejrocker: cosmicdreams, no there will be a whole separate system for overrides that hasnt been spec'd yet
(01:27:35 PM) webchick: Crell: won't the namespacing alleviate that issue?
(01:27:36 PM) cosmicdreams: OK
(01:27:38 PM) hejrocker: crell it only reads out of the config dir
(01:27:47 PM) webchick: oh, even better.
(01:28:03 PM) hejrocker: on module install it looks for a config dir in that modules directory
(01:28:10 PM) Crell: OK, cool.
(01:28:11 PM) hejrocker: and installs any .xml files in there
(01:28:37 PM) hejrocker: any other questions before moving on? :)
(01:28:51 PM) Crell: Nyet.
(01:28:56 PM) cosmicdreams: why would you have multiple sml files in the config dir?
(01:29:02 PM) cosmicdreams: I mean xml
(01:29:06 PM) cosmicdreams: stupid fingers
(01:29:11 PM) hejrocker: mostly just for organizational neatness or to mak things more readable
(01:29:22 PM) hejrocker: image module ships with three defaults and i think it makes sense to have them separate
(01:29:43 PM) hejrocker: also the more atomic they are, the less memory they take up when read, and the more control we have over ram usage
(01:29:51 PM) cosmicdreams: one config file per module? (modules archives can have multiple installable modules)
(01:30:07 PM) hejrocker: one config directory per installable module
(01:30:12 PM) Crell: N config files per module, I believe.
(01:30:15 PM) hejrocker: right
(01:30:26 PM) Crell: hejrocker: Does that by implication mean that multiple modules in the same dir becomes a problem?
(01:30:35 PM) hejrocker: um, i hope not?
(01:30:43 PM) hejrocker: i would have to look at that code
(01:30:46 PM) ***hejrocker makes a note
(01:30:48 PM) davereid: yes, probably :)
(01:30:54 PM) ***Crell is OK if that's the case, but it should be known explicitly.
(01:31:15 PM) cosmicdreams: sometimes, you don't want to install all functionality that comes in a module (for example GMap)
(01:31:36 PM) cosmicdreams: does that mean that the config will be loaded but the functionality won't be turned on?
(01:31:42 PM) cosmicdreams: am I making sense?
(01:31:45 PM) fabsor: as long as you put your module in a directory, we should be fine?
(01:31:58 PM) webchick: yes, but many don't.
(01:32:12 PM) hejrocker: yes the module would have to be in a directory
(01:32:24 PM) fabsor: that does not sound as an unreasonable requirement
(01:32:24 PM) Crell: If we end up making a one-module-per-dir rule for D8, I'm fine with that.
(01:32:25 PM) hejrocker: we may want to mandate this in d8, i woudlnt mind but it requires more discussion obv
(01:32:42 PM) hejrocker: cosmicdreams, just because a config is installed does not mean functionality is enabled
(01:32:43 PM) webchick: For example, Views and Views UI are both in the root directory.
(01:32:50 PM) webchick: of modules/views
(01:32:56 PM) hejrocker: right
(01:33:05 PM) hejrocker: they can even nest
(01:33:07 PM) webchick: and iirc every single other module that makes that split does the same.
(01:33:08 PM) hejrocker: its just one module per dir
(01:33:17 PM) webchick: So probably want to run that past soe folks like earl, fago, etc.
(01:33:28 PM) pounard: does it really hurt to load too much config? I guess you never use it if the module isn't enable anyway?
(01:33:30 PM) hejrocker: can someone file an issue in the sandbox?
(01:33:46 PM) webchick: hejrocker: sure. what's the title?
(01:33:48 PM) hejrocker: pounard it shouldn't matter, it just sits there and gets loaded into the active store
(01:33:54 PM) hejrocker: http://drupal.org/sandbox/heyrocker/1145636
(01:34:06 PM) webchick: hejrocker: no, i mean the title of the issue. but thanks for the link. :)
(01:34:12 PM) pounard: yes, the active store is probably the only step you would to fix because of this issue then I assume
(01:34:25 PM) hejrocker: even that wouldnt matter
(01:34:42 PM) hejrocker: webchick something like 'address problem of multiple modules in a single directory sharing a single config folder'
(01:34:51 PM) webchick: cool thanks!
(01:35:00 PM) pounard: one question, when I read the image effect xml, does "effect" is the name for config('effect') calls?
(01:35:30 PM) hejrocker: pounard rephrase?
(01:35:42 PM) pounard: heu, what is the name for config() call?
(01:35:50 PM) pounard: is it in the xml file? (guess so)
(01:35:51 PM) hejrocker: it would be config('<filename>')
(01:35:55 PM) pounard: oh ok
(01:35:59 PM) Crell: config('foo.bar') => foo.bar.xml
(01:36:04 PM) hejrocker: config('<filename without .xml>')
(01:36:10 PM) cosmicdreams: cool
(01:36:11 PM) pounard: yes understood
(01:36:22 PM) hejrocker: ok i have two specific issues i want to get to
(01:36:31 PM) pounard: so you cannot merge multiple config files in only one then?
(01:36:40 PM) hejrocker: not at the moment
(01:36:44 PM) pounard: okzy
(01:36:44 PM) cosmicdreams: So if I created a module named baz, I could invoke config(foo.bar) to get foo.bar's default config?
(01:36:46 PM) webchick: hejrocker: done http://drupal.org/node/1299424
(01:36:47 PM) Druplicon: http://drupal.org/node/1299424 => Address problem of multiple modules in a single directory sharing a single config folder => Configuration management initiative, Code, normal, active, 0 comments, 1 IRC mention
(01:37:11 PM) pounard: hejrocker> is that something you want to solve or not?
(01:37:21 PM) hejrocker: cosmicdreams, you would get its current config. immediately after install it would be its default config, then changes get saved to the file as well
(01:37:36 PM) hejrocker: pounard eventually i would like to, but if we don't get to it its not the end of the world to me
(01:37:39 PM) cosmicdreams: That's rather nice
(01:37:43 PM) pounard: ok I see
(01:38:08 PM) hejrocker: So first
(01:38:31 PM) hejrocker: Right now variable_get()/set() work before the db runs by loading and working off $conf in settings.php
(01:38:40 PM) hejrocker: and we don't currently have any way to run without the database
(01:39:02 PM) hejrocker: here is that issue
(01:39:02 PM) hejrocker: http://drupal.org/node/1288142
(01:39:04 PM) Druplicon: http://drupal.org/node/1288142 => Modify variable_set() / variable_get() to use the config system => Configuration management initiative, Code, normal, active, 2 comments, 2 IRC mentions
(01:39:30 PM) hejrocker: I am starting to come to the conclusion that somehow we are going to need a solution for pre-db config stuff
(01:39:36 PM) pounard: hejrocker> the base system has no db independent implementation?
(01:39:40 PM) Crell: hejrocker: Would moving the DB code to PSR-0 autoloading let you load the DB on demand earlier?
(01:39:50 PM) hejrocker: crell is that something we want?
(01:39:55 PM) Crell: It's on my radar to do.
(01:40:06 PM) pounard: like a DrupalConfigStorageArray ?
(01:40:07 PM) fabsor: PSR-0 will help a lot
(01:40:08 PM) Crell: \Drupal\Database\... or possibly \DBTNG\... if we can make it fully independent.
(01:40:09 PM) hejrocker: crell i thought you wanted to mvoe db loading LATER
(01:40:20 PM) Crell: Well yes, after the 1 November Massacre. :-)
(01:40:28 PM) fabsor: right now we can't even get the class loaded properly =)
(01:40:29 PM) hejrocker: no i mean later in bootstrap
(01:40:34 PM) Crell: Oh.
(01:40:35 PM) pounard: Crell> DBTNG namespaced would be something nice
(01:40:45 PM) Crell: Right now "load the DB" means including the base files.
(01:41:02 PM) Crell: If those base files instead are PSR-0 autoloaded, then we can make them available earlier without preloading the code.
(01:41:03 PM) hejrocker: crell the way i understood it, your ideal was to push back loading the db as far into bootstrap as humanly possible
(01:41:10 PM) Crell: The only catch would be the wrapping functions.
(01:41:14 PM) pounard: Crell> we'd still need DB credentials
(01:41:18 PM) Crell: True.
(01:41:34 PM) Crell: So we still need the super-early-bootstrap-config.xml file we discussed.
(01:41:34 PM) pounard: so there is a tiny bit of config that is indeed needed before db
(01:41:44 PM) hejrocker: Someway we are going to need a one-off early bootstrap solution
(01:41:45 PM) Crell: For DB/memcache credentials, per-server config, etc.
(01:41:47 PM) pounard: yes, might not be xml after all
(01:41:59 PM) hejrocker: agentrickard will want it for DA stuff
(01:42:03 PM) pounard: could still be an array, and use a DrupalConfigStorageArray instance
(01:42:18 PM) hejrocker: fabsor suggested we have a new static class for this
(01:42:24 PM) pounard: or environment related using DrupalConfigStorageEnvironment
(01:42:25 PM) Crell: static class?
(01:42:31 PM) fabsor: not a static class
(01:42:32 PM) hejrocker: see the issue
(01:42:38 PM) hejrocker: i stated that poorly
(01:42:58 PM) hejrocker: i was thinking it could just be another xml file, and if we are in <x> bootstrap level we just skip the active store and read the filesystem instead
(01:43:05 PM) hejrocker: as a somewhat hackish solution
(01:43:11 PM) ***Crell doesn't know what a static class is, other than a class that contains only static methods. And I will strangle you with your own entrails for that. ;-)
(01:43:25 PM) fabsor: I never suggested such a terrible thing
(01:43:26 PM) hejrocker: crell he means a config class that read a static file
(01:43:36 PM) hejrocker: rather than the db
(01:43:36 PM) Crell: Ah, hard-coded to a specific file name.
(01:43:41 PM) hejrocker: or somethign
(01:43:42 PM) Crell: Interfaces FTW
(01:43:45 PM) fabsor: yes, now we are getting there
(01:43:52 PM) Crell: That would be more reasonable, IMO.
(01:43:55 PM) fabsor: So we have a db storage config interface thingy
(01:44:17 PM) hejrocker: and $conf storage config thingie
(01:44:20 PM) fabsor: we need one that just fetches very early things that can be accessed the same way as all other configs
(01:44:25 PM) hejrocker: which is as minimal as humanly fucking possible
(01:44:47 PM) hejrocker: another thing we will need in there is, for instance, the location of the config directory
(01:44:47 PM) cosmicdreams: What kind of variable(s) would be in this static file?
(01:44:52 PM) fabsor: first I tried to implement a config object to just transparantly replace the $conf array
(01:45:12 PM) fabsor: but I failed since we don't have a proper way of loading different storage "plugins" right now
(01:45:31 PM) hejrocker: cosmicdreams, anything we need to get the config system running primarly, plus other stuff that is needed very early in init. for instance domain access does some trickery in hook_init() that needs info extremely early
(01:46:01 PM) hejrocker: fabsor which is kind of why i was thinking of hardcoding it and punting until larry gets farther along
(01:46:25 PM) Crell: That file may need to be PHP, not XML, since it needs to be in a globally consistent location.
(01:46:27 PM) pounard: you need a fixed config file
(01:46:41 PM) Crell: It can't be hidden in  a config_23452624534 directory.
(01:46:44 PM) hejrocker: crellso basically we are accepting that settings.php will live
(01:47:00 PM) pounard: Crell +1, the config API seems flexible enough to read anything
(01:47:01 PM) Crell: I don't see a way around that at the moment, sadly. :-(
(01:47:08 PM) fabsor: I think something along the lines of what we already have is good enough for this things (settings.php)
(01:47:24 PM) Crell: The first config file we'll want for WSCCI is context handler mapping.
(01:49:02 PM) hejrocker: so how will this get implemented? will it basically replace whatever code boots up $conf right now?
(01:49:16 PM) Crell: Shouldn't we be asking you that? :-)
(01:49:28 PM) hejrocker: then the config system will need to know that this one request gets that data instead of data from the xml file
(01:49:42 PM) hejrocker: which will be easier when we have a real factory and etc
(01:51:06 PM) hejrocker: So having decided that for now settings.php lives, and for now that is our answer to early bootstrap issues, i think we can proceed
(01:51:11 PM) fabsor: right now we don't have a factory at all, we just load that one storage we have
(01:51:12 PM) hejrocker: in one way or another
(01:51:14 PM) hejrocker: right
(01:51:48 PM) hejrocker: so that is item #1 on the agenda
(01:51:55 PM) hejrocker: unless anyone has anything to add
(01:52:10 PM) fabsor: me!
(01:52:11 PM) Druplicon: Provides shortcut paths to current user's pages, eg user/me, blog/me, user/me/edit, tracker/me etc. http://drupal.org/project/me
(01:52:20 PM) hejrocker: ...
(01:52:33 PM) cosmicdreams: #1 is to rework settings.php or to code up the Factory method that will be used to load config in the future?
(01:52:35 PM) fabsor: I think if we improve upon the config "factory" a bit, we could actually use the same system for now
(01:52:50 PM) fabsor: just so that we can load another verifiedstorage
(01:53:01 PM) fabsor: we could then get things out of the same system which would be a win
(01:53:02 PM) Crell: Having a clean factory that can handle this base-level swappage is the next step, I agree.
(01:53:12 PM) hejrocker: Yeah me too
(01:53:37 PM) hejrocker: Who wants to take that on!
(01:53:37 PM) fabsor: we could store things handled in bootstrap in like 'core.bootstrap'
(01:53:54 PM) cosmicdreams: core.bootstrap.xml?
(01:53:56 PM) fabsor: and that bin will use a DrupalVerifiedStorageArray or whatever
(01:54:05 PM) pounard: DrupalVerifiedStorageArray +1
(01:54:30 PM) hejrocker: cosmicdreams, it probably won't be xml, it will just use the existing settings.php for the time being
(01:54:37 PM) pounard: sign the settings.file if needed, but laod from the $conf global, and you have a graceful migration from settings.php to config
(01:54:41 PM) fabsor: if we get that in place very early
(01:54:42 PM) hejrocker: yup
(01:54:44 PM) hejrocker: exactly
(01:54:57 PM) fabsor: exactly :P
(01:54:58 PM) hejrocker: fabsor we can replace whatever drupal code loads $conf right now
(01:55:25 PM) fabsor: if we could add a __set__ and __get__ on the config object, it will be seamless
(01:55:36 PM) hejrocker: that is controversial atm
(01:55:40 PM) fabsor: what we have right now is not very pretty anyway :P
(01:55:53 PM) hejrocker: i dont know if we have a wide-ranging standard on magic functions atm
(01:56:02 PM) hejrocker: other than every time they come up bikesheds ensue
(01:56:02 PM) Crell: __get/__set are not as transparent as you think they are. :-)  Not once you have arrays.
(01:56:43 PM) fabsor: look at the bottom of this: http://drupalcode.org/sandbox/heyrocker/1145636.git/blob/refs/heads/8.x-file-config:/includes/config.inc
(01:56:50 PM) fabsor:  if ($key[0] != '_') {
(01:57:00 PM) fabsor: yehaa :P pretty pretty
(01:57:09 PM) hejrocker: works > pretty
(01:57:20 PM) pounard: hehe
(01:57:25 PM) pounard: hejrocker +1
(01:57:45 PM) hejrocker: i can have this fight with you and larry all day :P
(01:58:00 PM) fabsor: I could try and take this on
(01:58:14 PM) pounard: I prey for nice myself, but this was a good one to defend yourself :)
(01:58:22 PM) hejrocker: that would be cool, maybe letharion can help you
(01:58:41 PM) fabsor: he was kind of scared when I started rambling the last time, but I will ask him
(01:58:43 PM) hejrocker: innovation friday!
(01:58:45 PM) Crell: hejrocker: At what point do you want to discuss namespacing and PSR-0ing this stuff?  We've already done that in WSCCI.
(01:58:45 PM) hejrocker: haha
(01:59:03 PM) letharion: letharion: Sorry, I didn't realize there was meeting today :(
(01:59:03 PM) ***letharion is reading backlog noq
(01:59:05 PM) letharion: s/q/w
(01:59:09 PM) hejrocker: crell im not completely in tune with the implications there, but i dont think we have time to tonight as i still have one topic to discuss
(01:59:19 PM) hejrocker: maybe we can talk in SF
(01:59:23 PM) hejrocker: or before
(01:59:23 PM) Crell: OK.
(01:59:41 PM) Crell: I'm praying that we can get the Symfony patch in by then, with or without the rest of wscci.
(01:59:48 PM) fabsor: Crell: you have the PSR-0 stuff in?
(01:59:48 PM) Crell: That will include the namespace stubs so you can start using it.
(02:00:06 PM) cosmicdreams: I'm lost what does PSR-0 mean?
(02:00:06 PM) Crell: fabsor: It's in the wscci sandbox, and I will reroll it later tonight, probably, with the 2.0.4 releases.
(02:00:25 PM) fabsor: Crell: awesome! will have to have a look at that
(02:00:26 PM) Crell: The only blocker on that getting into core right now is catch not being convinced it's appropriate to put in without a serious implementation using it.
(02:00:39 PM) pounard: cosmicdreams> PSR-0 is class naming convention for unfying all framework autoloaders
(02:00:43 PM) hejrocker: cosmicdreams, it is basically a file/directory naming convention which is used to help autoloading of classes
(02:00:59 PM) cosmicdreams: Interesting.
(02:01:01 PM) Crell: cosmicdreams: http://drupal.org/node/1240138
(02:01:03 PM) Druplicon: http://drupal.org/node/1240138 => Adopt PSR-0 namespace convention for core framework classes => Drupal core, base system, normal, active, 56 comments, 3 IRC mentions
(02:01:21 PM) Crell: Complete background, proposal, discussion.  The only holdup right now is procedural, not technical.
(02:01:32 PM) You are now known as davereid|brb
(02:01:37 PM) hejrocker: ok so this is my other topic of discussion
(02:01:38 PM) hejrocker: http://drupal.org/node/1288090
(02:01:39 PM) Druplicon: http://drupal.org/node/1288090 => Investigate better alternatives for encode() / decode() functionality => Configuration management initiative, Code, normal, active, 0 comments, 1 IRC mention
(02:01:56 PM) hejrocker: basically when we moved to xml i hacked together some xml encode and decode functions based on whatever i found on the net
(02:02:33 PM) Crell: What is stored in the active store?  XML, JSON, PHP?
(02:02:38 PM) hejrocker: XML right now
(02:02:42 PM) hejrocker: non-prettified xml
(02:02:54 PM) hejrocker: the future of that is tbd
(02:03:50 PM) hejrocker: i am kind of interested in investigating mysql's xml introspection capabilities
(02:03:56 PM) hejrocker: but that is a topic for another day
(02:04:22 PM) hejrocker: regardless i would love for someone to do some research into alternatives for this encoding and decoding of the xml to/from php
(02:04:23 PM) pounard: ohalala, the decode function really is hacky
(02:04:29 PM) pounard: :)
(02:04:35 PM) hejrocker: right now i think we are accepting that everything is going to/from arrays
(02:04:40 PM) hejrocker: pounard hacky but FAST!
(02:04:51 PM) pounard: that's a good point
(02:04:54 PM) Crell: One of the many reasons I like focusing on interfaces, not implementation.  If done right, implementation can change at any time. :-)
(02:05:21 PM) hejrocker: Yes I'm looking to change it now :)
(02:05:29 PM) pounard: json_encode really can use a simplexmlelement?
(02:05:33 PM) hejrocker: yup
(02:05:38 PM) pounard: Crell +1
(02:05:42 PM) hejrocker: someone pointed it out to me in one of the threads of doom
(02:06:16 PM) pounard: http://www.php.net/manual/fr/book.simplexml.php#105330 gotcha
(02:06:28 PM) hejrocker: one thing about running everything through json right now is we have no way to implemented mixed arrays of objects and vice versa
(02:06:36 PM) hejrocker: which may not be a long term solution
(02:06:37 PM) Crell: Nifty.
(02:06:53 PM) pounard: hejrocker> this method needs to be able to parse attributes as well, in the future, at least for language?
(02:07:00 PM) hejrocker: of course if we want that we need a way to implement them in xml too
(02:07:05 PM) hejrocker: pounard correct
(02:07:16 PM) Crell: hejrocker: That's where a more involved xml schema will likely be necessary.
(02:07:21 PM) fabsor: have talked at all about schemas?
(02:07:24 PM) hejrocker: yes if we decide to do it
(02:07:26 PM) Crell: Although I suggest we consider the xml format itself non-final for another year or so. :-)
(02:07:37 PM) hejrocker: fabsor no not at all other than wanting to keep it as simple as humanly possible
(02:07:50 PM) fabsor: are we thinking about one schema to rule them all ?
(02:07:59 PM) cosmicdreams: hejrocker: i'd like to help out this initative.  What's the best way to get started?
(02:08:32 PM) Crell: fabsor: It would have to be either one universal schema or direct property->element mapping like now.
(02:08:42 PM) Crell: Allowing different modules to define different schemas would be a nightmare.
(02:09:00 PM) Crell: Remember, the XML file is really just a human-editable alternative to serialze()/unserialize().
(02:09:00 PM) fabsor: Crell: well, kind of like it is now with different exportables I guess =)
(02:09:39 PM) hejrocker: cosmicdreams, the only pointer I have right now is to follow and try to get involved in issues in the queue. i have been trying to keep a number of issues there that are approachable to new people, but as you can tell we are still very steeped in high level architecture which can make it difficult somewhat
(02:10:02 PM) hejrocker: cosmicdreams, however you can always start digging into the code in the git repo and seeing what doesn't make sense to you.
(02:10:14 PM) cosmicdreams: cool
(02:10:14 PM) hejrocker: cosmicdreams, are you going to any drupal events in the coming couple of weeks?
(02:10:53 PM) hejrocker: i will be holding code sprints at badcamp and pacific northwest drupal summit
(02:11:06 PM) hejrocker: and maybe diwd although that is looking less likely atm
(02:11:27 PM) hejrocker: i was super happy with how the copenhagen one went
(02:11:41 PM) fabsor: until I showed up =)
(02:11:51 PM) hejrocker: eh i just ignored you :P
(02:11:59 PM) cosmicdreams: I'm going to Denver's DrupalCon
(02:12:10 PM) hejrocker: cosmicdreams, well thats a little far in the future :)
(02:12:21 PM) hejrocker: if we dont have some stuff in core by then i will cry
(02:12:31 PM) cosmicdreams: That's all I have funds for.  But I'm looking to help out where I can.
(02:12:39 PM) hejrocker: cosmicdreams, where are you located?
(02:12:48 PM) cosmicdreams: Minnesota
(02:13:06 PM) hejrocker: hm, im not sure of any events coming up near you. drupalcamp there was last month i think
(02:13:25 PM) cosmicdreams: me: https://plus.google.com/106029910359400047659/posts
(02:13:50 PM) Crell: cosmicdreams: Would you be able to make it to Madison or Milwaukee?
(02:14:21 PM) cosmicdreams: I should be able to make Madison, if I can get clearence to go.
(02:14:25 PM) cosmicdreams: When are those?
(02:15:16 PM) Crell: Nothing yet, but there may be something there before Denver.
(02:15:23 PM) ***Crell fans the rumor mill.
(02:15:25 PM) Crell: No guarantees, though.
(02:15:31 PM) hejrocker: Getting involved person-on-person is always the best way. Otherwise the best I can suggest is to start digging into the code and following the issue queue. Soon we will be looking into more implementations which will be a great place to help when we get there, but I predict more roadblocks until we're ready for that
(02:15:45 PM) cosmicdreams: neat.  VERY interested.  Could be able to bring some of our in-house devs too.
(02:15:46 PM) Crell: Yeah, WSCCI is in the same place.
(02:15:56 PM) Crell: Still very early to onboard en-masse.
(02:16:33 PM) cosmicdreams: We have a ton of hard-core PHP devs working here, (The Nerdery).  I've been trying to get them to look at the code that's in development.
(02:16:35 PM) hejrocker: xml encoding/decoding might be someplace where you could help if you're familiar with those issues at all
(02:17:03 PM) cosmicdreams: We have one guy, who has become a Drupal dev over the past month, that has a lot of previous experience with Symphony
(02:17:30 PM) cosmicdreams: He was very excited to hear that it had been selected for inclusion into the Drupal codebase.
(02:17:33 PM) hejrocker: he might be able to help crell actually
(02:18:17 PM) hejrocker: so there is one other thing going on, gabor has asked to get an update on where things are going, because he wants to make sure we aren't digging ourselves into a hole from the multi-lingual perspective
(02:18:34 PM) hejrocker: we are going to schedule a meeting in the coming week, but the times are super-ugly because i want catch there
(02:18:55 PM) hejrocker: crell are you interested in being in on that?
(02:20:08 PM) hejrocker: ...
(02:20:09 PM) cosmicdreams: It sounds that once the config files are up and running loading language files would be exactly the same.  A xml file to load up a db with translations.
(02:21:08 PM) Crell: hejrocker: I probably should be, yes.
(02:21:10 PM) hejrocker: cosmicdreams, we are actually talking about using language as attributes
(02:21:15 PM) hejrocker: so it would be like
(02:21:20 PM) Crell: Context sensitive config is something we are going to have to have, but I haven't a clue how.
(02:21:38 PM) hejrocker: <site_name lang="en">Hey Rocker!</site_name>
(02:21:49 PM) hejrocker: <site_name lang="se">Hej Rocker!</site_name>
(02:21:51 PM) hejrocker: etc
(02:22:01 PM) hejrocker: Gabor really wants it on a per-property basis
(02:22:04 PM) Crell: But what about other context information?
(02:22:07 PM) hejrocker: id much rather have it on a per-config-object basis
(02:22:15 PM) Crell: Eg, per-domain config, like agentrickard is going to need.
(02:22:22 PM) hejrocker: i dont know
(02:22:45 PM) hejrocker: i dont know how we meld multiple contexts without killing ourselves
(02:22:47 PM) agentrickard: well, right now, I dynamically populate $conf
(02:23:04 PM) hejrocker: and you still could
(02:23:25 PM) hejrocker: crell its quite possible that DA runs before context is loaded, and modifies what goes into it
(02:23:38 PM) Crell: Eh?
(02:23:41 PM) hejrocker: um
(02:23:44 PM) Druplicon: WUT?
(02:24:07 PM) cosmicdreams: should we make note on how Zend handles the domain specific context in config files?
(02:24:19 PM) Crell: Looking at other systems++
(02:24:24 PM) cosmicdreams: Crell I hear you're a Zend master so I probably don't have to remind you.
(02:24:29 PM) hejrocker: drupal bootstraps, DA comes in and grabs some stuff that would normally go into the context object, modifies it to its own needs, spits it back
(02:24:38 PM) ***Crell has never used ZF actually. :-)
(02:24:52 PM) Crell: Context object or config object?
(02:25:00 PM) hejrocker: cosmicdreams, i did look at that stuff some, but one of the issues we have is we have a potentially infinite number of contextually-sensitive config specifications
(02:25:03 PM) Crell: I was talking about getting context-sensitive configuration.
(02:25:06 PM) You are now known as davereid
(02:25:09 PM) Crell: So sitename varrying by domain, for instance.
(02:25:13 PM) ***hejrocker is just confused now
(02:25:32 PM) Crell: <site_name domain="foo.com">Hello, Rocker</site_name>
(02:25:39 PM) hejrocker: agentrickard, how do you handle that right now
(02:25:46 PM) Crell: DA can do that now because it can always just hack global $conf with its own stores.
(02:25:49 PM) Crell: I think...
(02:25:59 PM) hejrocker: we can always build it into the override system
(02:26:01 PM) agentrickard: I inject a bootstrap phase between settings load and hook_boot()
(02:26:03 PM) hejrocker: hook_config_alter
(02:26:08 PM) ***hejrocker hides
(02:26:11 PM) cosmicdreams: @Crell Oh? my bad.  @hejrocker: config per domain was a special case for Zend-based config.  Used a lot to discriminate between development vs staging vs production environments.
(02:26:19 PM) hejrocker: cosmicdreams, yeah
(02:26:30 PM) agentrickard: hejrocker: where are you loading the context in d8?
(02:26:37 PM) hejrocker: agentrickard, ask crell
(02:26:43 PM) cosmicdreams: and it was cascading so that you could have a common config between them.
(02:27:10 PM) hejrocker: cosmicdreams, right thats more what we're looking into the overrides system for
(02:27:24 PM) cosmicdreams: http://framework.zend.com/manual/en/zend.config.html
(02:27:31 PM) cosmicdreams: I suspect you didn't need that link
(02:27:34 PM) hejrocker: :)
(02:27:41 PM) cosmicdreams: but I just thought I should post it anyway
(02:28:16 PM) cosmicdreams: files could look like this: http://framework.zend.com/manual/en/zend.config.adapters.ini.html
(02:28:24 PM) cosmicdreams: which is super simple
(02:28:59 PM) hejrocker: i may have to kick catch|afk out of this multi-lingual meeting due to time zone craziness
(02:29:05 PM) hejrocker: he can catch up later
(02:29:12 PM) Crell: agentrickard: The plan is that there is a baseline config file that we load that is just a mapping of context keys to handler class names, basically.
(02:29:17 PM) Crell: That populates the root context object.
(02:30:15 PM) hejrocker: i think DA might be able to exploit the overrides system for its needs if we design it right
(02:30:28 PM) agentrickard: well, I need to be able to alter that dynamically either a) before it is loaded so that my values are not changed; or b) after it is loaded but _before it is used by anything else_
(02:30:29 PM) Crell: Beware of alter hooks. :-(
(02:30:33 PM) ***hejrocker notes there's a reason we only design one thing at a time
(02:30:38 PM) Crell: agentrickard: The context, or the config?
(02:30:48 PM) agentrickard: I don;'t understand the distinction
(02:30:59 PM) agentrickard: the context (currently) alters the config
(02:31:06 PM) Crell: Context is "the HTTP request plus derived stuff".
(02:31:11 PM) agentrickard: by preloading $conf
(02:31:13 PM) Crell: That includes the domain of the request.
(02:31:24 PM) Crell: Config is "stuff stored on disk that the admin specified."
(02:31:25 PM) agentrickard: I need to modify config based on domain context
(02:31:34 PM) Crell: Right.
(02:31:43 PM) Crell: How we do that in the new system we don't know yet. :-)
(02:31:47 PM) agentrickard: allowing a domain-specific or context-specific file would be lovely
(02:31:57 PM) agentrickard: or dynamic overrides
(02:32:02 PM) agentrickard: or both ;-)
(02:32:19 PM) fabsor: sorry if I missed something above, but how would we handle more than one "domain" then, like domain and language
(02:32:48 PM) fabsor: would we have something like <key domain="domain" lang="lang">value</key>
(02:32:59 PM) hejrocker: fabsor right now my idea is we support language out of the box, and basically domain access has to hack the overrides system
(02:33:04 PM) Crell: That's what we're trying to determine, since there's at least two contexts that are relevant: domain and lang.  And if there's 2, that means there's a potentially infinite number.
(02:33:24 PM) hejrocker: right
(02:33:27 PM) fabsor: ugh
(02:33:31 PM) hejrocker: and we cant support that
(02:33:33 PM) hejrocker: we need another way
(02:33:44 PM) hejrocker: we can only support what core needs and enable what contrib needs
(02:33:51 PM) Crell: If Spaces ever gets ported past Drupal 6, that's another config-changing-context.
(02:34:00 PM) Crell: er, config-changing context.  (Hyphens are relevant!)
(02:34:23 PM) Crell: But those should not be totally different systems.
(02:34:26 PM) fabsor: <domain="example.com"><domain="sv"><key>value</key></domain></domain>
(02:34:38 PM) fabsor: parsing fun!
(02:34:44 PM) hejrocker: as an example
(02:34:51 PM) hejrocker: lets say we have a folder called overrides
(02:34:54 PM) hejrocker: all the overrides go in there
(02:35:11 PM) hejrocker: DA could make separate folders in there for its config files, one per domain its modifying
(02:35:13 PM) hejrocker: or something
(02:35:18 PM) hejrocker: im just making this up as i got along
(02:35:30 PM) hejrocker: and then it can merge them in on the fly
(02:35:41 PM) pounard: Crell> if context gives the config (e.g. $context['config'] with the current syntax) any module could override it at any point
(02:36:17 PM) Crell: Oh dear god no. :-)
(02:36:37 PM) fabsor: hook_context_alter !!! woho
(02:37:00 PM) ***Crell stabs fabsor.
(02:37:00 PM) hejrocker: im happy to punt this for now
(02:37:05 PM) hejrocker: i dont want to get hung up on it
(02:37:08 PM) Crell: hejrocker: Not for too long, though.
(02:37:52 PM) hejrocker: no but long enough to start getting some implementations working and work through these other issues
(02:38:06 PM) cosmicdreams: so #1 is to create the factory method?
(02:38:17 PM) Crell: Factory class, probably, but yes.
(02:38:28 PM) cosmicdreams: that's what I meant
(02:38:31 PM) cosmicdreams: sorry
(02:39:14 PM) cosmicdreams: heyjrocker:  I think you may have previously written a post talking about how you looked at Zend_Config and turned it down.  Do you have the link to that?
(02:40:27 PM) pounard: (Crell) Oh dear god no. :-) => was it for the context responsible to give the config object?
(02:40:36 PM) hejrocker: cosmicdreams, let me find it
(02:40:53 PM) Crell: pounard: Yes.
(02:40:57 PM) pounard: Crell> why not?
(02:41:01 PM) cosmicdreams: because we're kind of talking about a solution that looks like : http://framework.zend.com/manual/en/zend.config.adapters.xml.html
(02:41:16 PM) Crell: Circular dependency, since context depends on configuration.
(02:41:43 PM) Crell: The context system is not a catch-all DIC.  It's just a DIC for request-derived data.
(02:41:43 PM) hejrocker: i do need to wrap this up, i have to get up to catch a plane in… six hours
(02:41:55 PM) pounard: Crell> no circular dependency then
(02:41:59 PM) cosmicdreams: rock on
(02:42:10 PM) pounard: config already is boostrapped, context can give it to people from then
(02:42:15 PM) Crell: If we want to have a DIC for configuration or for logic (plugins), I'm open to that but it should be a separate thing.
(02:42:22 PM) pounard: the opposite would have been circular
(02:42:44 PM) pounard: (config using context)
(02:44:16 PM) hejrocker: DIC?
(02:44:26 PM) fabsor: Dependency Injection container I guess
(02:44:29 PM) pounard: dependency injection something
(02:44:35 PM) pounard: yes probably container
(02:44:41 PM) You are now known as davereid|phone
(02:44:53 PM) hejrocker: ah yeah
(02:44:56 PM) fabsor: or first hit on google: http://en.wikipedia.org/wiki/Disseminated_intravascular_coagulation
(02:45:23 PM) pounard: Crell> not easy, but contextual configuration override would be really powerful, and in order to make this work you'd definitely need to be the one that gives the config to the developer
(02:45:25 PM) Crell: Dependency Injection Container, yes. :-)
(02:46:00 PM) Crell: pounard: I could be convinced to have a Config DIC, perhaps, but not merging it with the Context DIC.
(02:46:28 PM) Crell: Although if the config object is already injected into anything using it (eg, plugins), then it's not really necessary to wrap another layer around, is it?
(02:46:51 PM) hejrocker: so im going to bolt, anyone have anything else they want to talk about?
(02:47:02 PM) hejrocker: this meeting was much more lively than the last which is awesome
(02:47:12 PM) Crell: hejrocker++
(02:47:27 PM) Crell: hejrocker: So when can we get a config system in core that Context API can use? :-)
(02:47:45 PM) hejrocker: crell i want two implementations in place
(02:47:55 PM) hejrocker: then the core patches start
(02:48:28 PM) Crell: So, what can happen by badcamp?
(02:48:38 PM) ***Crell would love it if we could both get something into core by then, but not sure how reasonable that is.
(02:49:15 PM) hejrocker: crell well if we can get site information done (which i think relies on the early bootstrap stuff) and if we can get image styles done (which i think can be done now)
(02:49:20 PM) hejrocker: then im ready to start pushing patches
(02:49:28 PM) Crell: Cool.