 I can sit right up front, and I promise not to make an example of it. If I spill, do you mean throw? If I spill, do you mean throw? Yes, yes. Hi, everybody. So this is my core conversation on the status of the configuration management initiative. Yes, a question? No, I'm just kidding. So for those who don't know, my name is Greg Dunlap. I am Hey Rocker on Twitter, and I'm the lead of the configuration management initiative. So for those who haven't been around, here is a brief history of the configuration management initiative to this point. At Drupalcon, Chicago, Dries asked me to lead this initiative, and I went to my employer and said I need time to do this. And my employer then, node one, now, Wunderkraut, but I don't work there anymore anyways. Not because of anything bad, they're all fantastic people. Said, I will give you 50% of your billable hours to work on this configuration management initiative, which was awesome. So I put together a code sprint in conjunction with Drupal Camp Colorado later that year. It was myself and David Strauss and Larry Garfield and Chex and Angie with some assistance from Greg Nattison and Ben Jeevens. And we came up with the initial architecture for the configuration management system. And I mostly, with some help from various people, too numerous to name at this point, that coded that system up and got the first patch into core. And what happened after that was we began running implementations of this system into core. And at Drupalcon Denver last year, I started creating all of the issues to say convert this to core, convert this to core, convert this to core, and we had a code sprint and it was amazing and like 20 people showed up and like four people got their first core patches in and stuff like that. But another thing that happened at that code sprint was we started doing these implementations and we started realizing two things. First was that none of these implementations were really novice issues because every single one of them we found was like, we'd start working on it and we're like, oh, this needs to be done in the installer. Hmm, okay, so we'll do such and such. Oh, but in the installer we don't have a database yet. So how are we going to do this? And it was like, you'd see a little thread there and you'd start pulling on it and the next thing you know your entire sweater was on the floor and all you have is a pile of yarn. And so that was the first thing that happened at that. The other thing that happened at that was we started realizing because we had never actually used the system that we designed before and the various parts of it didn't work the way that we expected them to or the way that we wanted them to in various things. So from that we proceeded on a period of first off solving core issues that blocked our implementations that we were having or redesigning the implementations that existed in core to work better with the system in combination with re-architecting parts of the system to make it more flexible and more representative of the system we wanted. Ultimately what we really want is a system in which your configuration which as we've defined it is anything that's not an entity with an asterisk next to that being represented canonically in the file system and those files which always represent the current state of your system being able to be deployed to a second system on which you can press a button and have that configuration represented in whole on the new system. That's really the goal in the end. So here's what we've got right now. We do have configuration in the files right now. They're stored in YAML and they're represented. They're mostly tied in the way of saying a system one setting screen in the admin is represented by one file or in the case of something like image styles, one image style is represented by one file. Files are loaded into what we've called the active store. The active store is a database table which holds those files not in YAML but in serialized PHP because it's faster to use and since it's not and the files need to be more human readable but in the database we don't care we just want it to be fast. And that offers a nice separation because when you take a file and load it into the active store we may want to do some validation that says oh this isn't valid YAML get rid of this one or this isn't a valid view get rid of it and you can do that but what's in the active store is always known to be good so even if you push a syntactically invalid YAML file your site won't die because everything that gets actually gets loaded into the active store we know is good and it also acts as a caching mechanism because it's faster than reading from the files and things like that. We have a central API to manage our configuration data which we've never had before. One of the great problems of features is that features does not implement a central API which everything uses features implements its own API which everybody else has to implement and that's one of the reasons why features doesn't have all of the coverage of all of the contrib modules because they don't use it but also it can't control core which stores things in a hundred different formats depending on if they're users or if they're IP address lists or whatever and so a huge part of features is writing one of implementations for things in core that it doesn't have any other way to deal with. So we have a central API to manage the data that everybody's going to use. That's awesome. We have the basic ability at the API level to import new configuration or as of yesterday to do that through Drush thanks to Alex Pot. Did that get committed? No. Huh? Today or tomorrow. Today or tomorrow that'll get committed. So you can actually, you will actually be able to import configuration through Drush before you can do it through the UI. So the basic ability to actually import new configuration which is awesome. Modules can supply default configuration which is the default set of settings that a module ships with and when they're installed those settings are copied over into the live area and you know, that's great. And when you install your, when you install Drupal it creates a configuration directory. It copies over all these files and installs the new configuration. It deals with the configuration that it needs to in the setup screen, in the site information screen. It also doesn't deal with configuration that it needs before the database is loaded and all of these things. So this is all stuff that we've got which is great and we've made a lot of progress and it's awesome. Here's what we don't got and for each of these things I'm going to show you, I'm going to give you this list and then for each one of these I'm going to run through the dependency chain that we have to, that we have to solve in order to get these things into core and the decisions that we have to make because we are at a point in the cycle right now where we have some very tough calls to make because we have three months left for feature freeze and we have limited resources and very, very, very aggressive goals. And so I wanted to show and be very clear about because I think a lot of people don't realize the kind of things that happen in order to make some of these things work. So what we don't have is a user-facing interface for actually importing the configuration that you move from site to site. You saw Dries' keynote and he had that demonstration of that import happening. There was a little bit of hand waving going on there. What had happened was we created a UI, the UI it turns out was horribly broken unless you used it in this one very specific way and what Angie did was she used it in that one very specific way and when you do it looks really impressive. Unfortunately, if you do it any other way, it deletes all of the configuration on your site. If you can imagine going into a Drupal 6 site and simply deleting your variable table, that's about the extent of what we're talking about. So we decided not to commit it but she used it as a demo. We don't have multilingual configuration at all and we haven't converted all of core to the configuration management system at all. So let's talk about each of these things and what needs to be done to get them done. First, let's talk about multilingual configuration. There's really two aspects to multilingual configuration. There's translation of strings, which is one thing. Let me think of one. Like your site slogan, for instance. This is a piece of text that you type in a language and in other language you want it translated to each of those languages. The same text translated to each of those languages. That's one part of the multilingual stuff. The second part is what we're calling internationalization, which is different. Which is things like, I want my site's front page in French to be different from my site's front page in Spanish. Or I want to have ten nodes on my site's front page in French and five on my site's front page in Spanish. There are things that are different depending on the, or your site logo. That's another great one because it has nothing to do with text. It's an image, right? It's a path to an image. I want it to be different on this site than that site. It's two strings that are different, but they're not being translated. And that's a really key difference that we need to keep in mind when we talk about internationalization. And this is a really complicated problem space. If anybody was here for Gabor's presentation about the multilingual initiative, there's a lot of pieces to this pie and it's extremely complicated. And these sort of ways in which we've been hacking around it in corn can make implementing it even more complicated now. So here's a chart of what we need to do to have multilingual support. In Barcelona at Drupal Dev Days last year, we made a decision to implement a context system into the configuration management system. And what that means is that you will be able to modify your configuration based on a context of which a current language will be one that's implemented in core. You'll be able to do others like, for instance, domain access will be implemented almost certainly as a context on which configuration is changed. Or you can make one to set your local site settings different than your live site settings and things like that. But this is the one we're doing, multilingual support. So the first thing that it does is it implements symphonies, events and subscribers system, which means that you can... which is a way to sort of do hooks but not be tied to needing all of the modular parts of hooks that core needs to work. We also need metadata for configuration in order to store some stuff that translation needs. And then once both of those things are done, we can start implementing it and surfacing it in the CMI APIs. So events and subscribers, this actually got committed last night around 1.30 in the morning. So the way that this works is that you create a system and in your system you say at this point, oh, I'm going to fire off an event. Like, I'm saving a node, so I'm going to fire off the node save event. And then people who want to respond to that system can register themselves as listeners for that event and do things. The nice thing about this that's separate from hooks is that we don't have to have the system module loaded for this to work. It's completely tied to object-oriented code and the PSR0 class loader, which means that any of the code that it needs will be auto-loaded from the first time that it's called, which is really excellent, because that means that we can do this at any point in the bootstrap and setting up these contexts has to happen very, very early in the bootstrap for them to be effective. That was why we decided to go with this system, even though it's a system we haven't really used in core very much, but it's not very efficient enough. So that's actually been committed, so that's great. We need metadata for our configuration. This was something that I fought for a really long time, because Scope's creep in CMI has been something that I've had to chop away with an axe since the beginning. But one of the things that we really need to know is which pieces of configuration are translatable strings and which pieces of configuration are not, because one of the things that we have to do for the translators is they have all of these tools, which list all of the translatable strings in Drupal so that they can look at them and say, here's a string that I need to translate into another string. And without that, it's very, very difficult for them to tell what they need to translate and what they don't without digging through the code themselves. So if we're going to support translatability and configuration in any meaningful way, we have to introduce a metadata system that will store at least a key for a piece of configuration and whether or not it is a translatable string. And then the multilingual context implementation can look at those and grab them and translate them if it needs to. The tools that multilingual people use to grab translatable strings can grab them and that will be great. So there is a patch for this that exists. It's a very early implementation and we've already decided to scale it back some, but it needs to be revisited and committed. And then, of course, once these two dependencies are done, it needs to actually be... All of this stuff needs to be implemented in the CMI and surfaced and put together. So this is the simplest set of dependencies that we have to work with to make those three things happen. Well, it's next. Yes. By the way, it's interesting, if you type Tombstone Generator into Google, you get a surprising number of results. So we want to convert core systems, but really what we want to do is get rid of the variable system entirely. And they're not necessarily the same thing as we will see here. So in order to remove the variable system, there's two things. One of the things about the variable system is that there's a lot of stuff that's stored in it for duration. It's state information. A good example is the last time that Cron was run. This is stored in the very... Actually, is that still stored in the variable system? It is. Okay. Because I know we have that semaphore thing too that's stored in the locking system that was stored in the variable system. Right. There's things exactly like that. Another example is, for instance, this is actually really interesting, and I never knew about this until recently. If you delete a field from a bundle, what happens is that the field is not really deleted. What it's done is it's marked as deleted, and then it doesn't show up in the UI. And then in the background on Cron, all of the data in that field is periodically deleted until all of the data is gone, and then the field which has been marked as deleted is actually deleted. Now, there's the definition of the field which is definitely configuration, but the marking of the field as deleted is not configuration at all, because you don't want to deploy this to your live site. You want to... All you want to do is say to your live site, I deleted a field, right? Or this field is gone. And in our system right now, we have files, right? So if you have a new file that wasn't there before, it's a creation. If you have a missing file that was there before, it's a deletion. So what you want to have happen is the field system deletes the file, and it's gone, and that's it. If behind the scenes it wants to store that the field has been deleted, you don't want to store it in that file and leave the file there, because if you deploy that, it's going to screw up all sorts of state information because you're in the middle of a deletion on the remote site. This is one of the more complicated reasons why we need states separated from configuration. And this is the kind of thing where we need to start thinking about priorities. So we need to implement the system to store state. Marc Sanabom wrote a really nice key value store, which would be great for storing state. It's a nice separate component. It's completely separated from Drupal, and it could be used in any PHP system and it's PSR0 as a key value store. Marc Sanabom said, this is great, we should share this with the rest of the PHP community, just like we've been taking stuff that Symphony shared in exactly the same way. One of the interesting side effects of that is Drupal is GPO, but most of the modern PHP projects are MIT or Apache licensed, and they're not compatible. And so if we want to do that, we cannot commit that code to Drupal.org and share it, because then it becomes tainted and the other projects can't use it. So what we talked about doing is releasing it on GitHub, and then including it back into Drupal core as a remote vendor include like we're doing with the Symphony stuff, but still marking it as Drupal stuff because we wanted, you know, this is, and so long story short, there's a very long set of issues to actually get a state system into core which really have nothing to do with there being a state system in core, except for ancillarily. And one of the things that's interesting here that I think it's good to point out is that a lot of times in the community I think we make decisions about things that are about we want to do what's really right in the long run. And a lot of times I think those decisions are based on, you know, we have a three year release cycle and if we don't do it really right now we're stuck with it for three years and a lot of it is well if we commit this and it's GPL then we're stuck, and if we worry about these things and take time and time and time working them out some of our very high level goals are dead. And when we get this late in the release cycle we need to really think about what our priorities are overall. And this is a really good example of that because we could convert all of core to the configuration management system and do all of the implementations and we haven't even gotten to that thing over here yet. And we still wouldn't be able to remove the variable table because of all of this other stuff that's in it right now. So I just gave you the rant about state. Configurable thingies are something we're talking about. As we've converted things to core we've discovered that there's sort of two types of configuration in core. There's this stuff that goes into the variable table which is just data, one piece of data and there's stuff that's more like an implementation of an instance of a business object for instance an image style. A field type. A taxonomy vocabulary. These things have a different set of requirements than static data do and the set of requirements that they have are all common amongst each other. They need to be able to fire hooks when events happen. They need to be able to respond to hooks when events happen. They need to have crud functionality. They need to do their own special handling when the import and export process runs. So Sun came up with the idea that we should create a base class and interface for these to wrap the common functionality and that all of the things that implement this type of object could descend from that and then we'd have a nice system in core that represents how we feel that more complicated pieces of configuration should be implemented. And it's a really great idea and then it also presents a best practice for contrib to follow because one of the things that we do in core all the time is we implement subsystems and then we don't like fully follow through, implementing them through core and then contrib just follows what core does all the time and so we want to do what's right in core and what's standard in core as much as we can because contrib is just going to follow our suit and again if we don't we're stuck with it for three more years. So this is something that we're trying to sort out before we do the more complicated implementations because if we do the more complicated implementations we end up having to go back and do them all completely over again. So that was the second chain of dependencies in order to get in order to get core converted to the new system. Now UI for configuration so that you can do so that you can press that button and have it work. We need to have the import system finished. The basics of the import system are in and it works really well for the static variable kind of configuration but it's been largely untested for anything more complicated than that. We determined at certain point that the implementation we determined two things from the architecture standpoint while we were doing implementations. One is that having a single directory from which you save files and read files to import them into the system is problematic because you can have a situation where you push your files to the live site and then configuration changes are made on the live site which override the files that you just pushed. There are all sorts of ugly race condition things that can happen in that situation. So we decided that we would actually make it a two directory solution. Your live data is over here but you import config that you manage from over here and it actually has a really nice workflow. It's a little more complicated than the single directory solution but I have a graph, it's in an issue that I didn't have time to put in here or explain because we're going to be here for quite a while anyways. And it's really cool. The other thing that we realized is that in the current system with the active store the files are not truly canonical because you know, Earl was the one who brought this up first. If you deploy a view and views reads it in views wants to validate that that view is okay, that the object is created properly, that a config module didn't add some crap into it that's wrong and broke it or anything because if you import the view without doing that it can bust all sorts of stuff all over your site. So let's say that views imports this thing, it says it's broken and so it doesn't put it into the active store. Now what you have over here is broken stuff sitting in your live files directory but it's not actually being read because all the reads on a daily basis are coming from the active store. Your files at that point are not canonical anymore. You've got broken data there and we want to point where your files always represent the live version of your site. So Sun came up with this idea that we could do what we should do is actually make the files live storage and turn the and make the database just a cache for those files. But then I said if we do that we lose the ability that I like in the active store to protect people from pushing dead files but then we realized if we had a two directory solution then we have that back again and so these two things kind of happened at the same time. I wasn't supposed to be just nevermind. So we either need to keep with the active store or change to that and then we need to start testing out these complex implementations to make sure that they work. We need to implement UUIDs for configuration because otherwise we have no way to know if pieces of configuration have been renamed or not but we can't have the UIs be the file names for the configuration because we want those to be readable so that when you do a get status you can do it better than things like that and then finally we still need to do the configurable thingies that I told you about. So live import directories I just explained that file storage and cache I just explained that this and this all has to be done before we can even start testing pressing that button I showed you there and oh I passed the cat didn't I. There's more stuff still beyond that. That's just the stuff that we absolutely have to ship to make sure the entire initiative of failure. But let's talk about some other stuff. We have no way of versioning configuration right now. One of the things that views and C tools do is they allow you to say oh this configuration is for views version one and views version two has a new schema for its configuration and so you can tell when you upgrade to views two that the stuff that the exported views that you have from the old version are old and then views two and then you can throw a warning saying you need to update these and convert them and save them back out again. We can't do that if we if you try to upgrade it then either everything has to be upgraded in the upgrade process of the module or everything's going to fall apart. We have no we have no system for managing that right now. We have no system for cleaning up configuration after you remove it. Right now all of us have experienced variables tables that have 5000 entries in the module that aren't installed on the site anymore. We would really like to implement a way to not do that anymore in Drupal core but I can't prioritize it really because it's not a feature reversion it's just something that continues to suck and so I would really like to make things not suck anymore. We can't tell right now if config on a live site has been overridden since the last time you imported it like you can use it right now. I got into a big argument at Drupal con in Denver with a guy about this he came up to the mic and said how can I do this and I said you can't and he said why not and I said well just don't edit your data on the live site implement a proper workflow and he said well that's not realistic for our clients and I said well the reason it's not realistic for your clients is because right now in Drupal 6 and Drupal 7 it's impossible to implement a proper workflow and if it was possible then it would be very easy and now that you can you should and he did not like that answer and he posted a blog post to Drupal Planet complaining about how I was out of touch with the needs of community and this is typical of core developers who don't take into account end user needs and he got like 50 comments from people who said the same thing and after I got done wanting to burn everything down I realized I realized that if we're going to take over the functionality of what features does now then this would be considered a feature reversion but on the other hand it's difficult for me to say that this is a requirement because I don't think it is and honestly a contrib module could implement it if they wanted to we have all of the pieces in the system but as a matter of fact this guy from Denmark Zendike is he here he's back there he has already written a contrib module to do this and not only does it store that not only does it store the snapshots every time you import it keeps all of the old ones so that you can revert to like the one from five imports ago and back to this one and not only does it do that it has all of this web services remote site without moving any files around at all this is a contrib module that already exists that's awesome but we don't have this right now the config system absolutely implemented some performance reversions performance has taken a hit because of it but we can't even begin profiling it until the architecture changes we need to make are done because it's stupid to profile it now we're going to change all the architecture around thankfully this kind of stuff can be done after feature this this thing at least can be done after feature freeze but it still has to be done in addition to a lot of other stuff we wanted to do a UI for the multilingual stuff we wanted to be able to say in the user interface this field is a text field that is subject to translations or this widget needs a different widget for France than for Spain and all of this kind of stuff and we have no we have not have anything like that and that stuff will continue to live in contrib which is a shame content staging was my biggest priority when I started this initiative and I haven't had time to think about it at all thankfully people like Fago and Dick Olson and Link Clark have started thinking about it in the context of the idea that they're doing in Larry's initiative for a common data serialization format for for entities which is awesome but on the other hand Larry is probably going to have to scale back his initiative because he doesn't have enough help and that we're not going we may not ship natively with any web services in core at all we may just ship with the plumbing to make sure that you can implement them in a way that's not completely hacky um well I wanted to I wanted to I I thought I always thought that the two are combined because you should be able to replicate the pieces of your site between them as as needed and I never even wanted to implement a UI for content staging I always thought that as long as the pieces of core that are broken that prevent it now UUIDs for pieces of content so you don't have serial ID collision anymore the decoupling of the saving of content from the form system so that you can actually save stuff properly without having to do Drupal execute those kinds of things we can implement those that I don't care about implementing the UI contrib can take care of it and we haven't even gotten that far yet system settings form is completely broken with the new config system system settings form relies on a single key to write data into the variables table what we have right now is sort of a two key system the first key being the name of the file that data is stored and the second key being the piece of data stored in the file and um we will have to put together some kind of data binding solution basically into the form API to say this piece of data needs to be stored over here there is a patch in that queue I'm not even sure what its status is at this point because I haven't taken a look at it in a long time but if this doesn't happen we can, my opinion is we can ship without this because we've implemented all of the stuff with their forms and they're prepared for the possibility of a system settings form getting done and in but if it doesn't get done in then it doesn't I don't think anybody would disagree that it would really suck if we didn't do any of these things so this is where this is where we get to what we can do to help you know I had lofty goals for getting this system done and people like Sun and Alex Pot and Bejeebus and all sorts of people have been doing a ton of stuff to get this work done and we all have very limited resources obviously and it's a little frustrating to me when I talk to companies who are constantly coming up to me and telling me that this is the most important thing to get done in core and I'm pointing out to them that I'm doing something that will easily save them 100 man hours per project I mean we're talking about chopping a quarter of a million dollars off of estimates that they can use to market and ship to clients and then they tell me they don't have any time or money to donate to this initiative it makes me a little frustrated and so what we still need to get some stuff help and before I do that I would like to acknowledge the people who have helped up to this point my former employer Node 1 for a year gave me 50% of my billable hours to work on this project which is the only reason we got as far as we did now which is amazing Pantheon recently I've begun a fundraising drive to try and fund myself to to sorry to work on configuration management initiative full time from now until the end of feature freeze and Pantheon are the first people who step up and have pledged to give me $5,000 to work towards that and over the years Acquia has flown me and Sun and other people around to code sprints all over the place because we realize how productive it is to have people in one place I mean I can't I mean you know having me and White Shed and Swentel here Swentel has already written like the first patch for implementing field API and CMI and you know we've been sitting around and talking about it it's incredibly productive and we try and get as much done at these things before we wander off and Acquia has been really helpful with that but here's what we can do if you're interested in getting involved in the configuration management initiative you can I'm always on the Drupal CMI channel in IRC on freeno.net and anybody who's interested can get me there and I'm trying more and more as I can to organize much more specific tasks that people can work on that people can target because I understand that one of the one of the weird things about our community is that a lot of people have limited chunks of time like they may have 20 hours this week because they're in between projects but then they're gone and if I don't have a 20 hour chunk of work to do I have something that's like I need to work on this issue and we'll be done in three weeks I lose those people so that's one thing but of course with me working I'm contracting right now and so between contracting and chasing clients and working on this it's very difficult for me to organize that stuff and review patches and do the other stuff that I need to do this is the link to the open CMI issue list right now it's a little difficult because we have a lot of big architecture issues but as we resolve those and a lot of those are getting resolved or at least to the point where they have patches that are worthy of review that'll be a great place to get involved and the highest priority ones are always more critical and major so you can focus there as I said before I'm looking for funding to get myself to work on CMI full time through the end of the year because as you see here we have a lot of stuff that we want to do and I really want to do it and I would really prefer to be doing that then hacking form alters into Drupal 7 websites for clients you know and I think there's a lot more value in me to do that but I have to eat and feed my cat and things and so if you work for a company that you think might be interested in funding the configuration management initiative or you own or represent a company that you think might be interested in funding the initiative then get in touch with me I have detailed funding proposals written up and I would love to talk to you about getting involved and another thing that would be really helpful is resource donation which is that a lot of people because of their budgets or whatever can't donate money but they have people with spare time who would like to get involved I would love to talk about that as well one of the things that's really valuable to me there is if you can promise that your developer will have five hours a week to work every week that's incredibly valuable to me much more than I have a developer who can work 40 hours for the next two weeks because I don't have to ramp those people up I have a reliable resource that I can work on and plan for one of the things again about our community is that it's very hard to plan timelines and milestones when our resources are scattered all over the place and coming and going and things like that so if you have anything like that please talk to me I would love to hear about it and that's the end of my presentation and now if anybody has any questions for the next 20 minutes I would love to talk and answer them I have a quick question can you walk us through what a deploy looks like in a CMI world where this worked in your ideal case with all the cool stuff is done yes as soon as my computer I don't know why this is happening because I am actually plugged in over here I'm plugged into an outlet that's not plugged in it doesn't matter I'm done an ideal deploy to me would be for instance you have a bunch of developers who work on a site they work they are periodically committing their configuration changes to get mentally you would probably enter into a similar workflow that you do in features you create a view you do a Drush FU you do a diff to make sure that you have updated the things that you think you are going to update and you commit it to get and people can merge those in and work on it on their sides the workflow would be very similar to that except you wouldn't actually have to specifically run the update and in an ideal world it will cover everything and you don't have to write update hooks and things like that you commit those to give and they will either through a Drush command as part of your build process or through the UI say oh look I've got new configuration punch a button or it will happen in your build scripts and that configuration would be loaded and then become live on your system you work and work and work and work and then you could take the configuration that's now in that get repository, push it to a staging site run the same process everything is great they say oh you know I need some changes here and then they make them on the staging site and you're like oh crap they made it on the staging site but thankfully you have an import directory that's separate from your live directory so the stuff that they make the staging site could actually be in a different get repository and this is where the diagram that I have is really useful that gets pushed back to the developers and they can import that back into their site and you can do a circular workflow going which is really useful for pushing stuff back and forth especially if you have clients who are enabled to do things like munch views on their own and things like that which in an ideal world we would all love and we can't do now because it makes our lives hell then you take that stuff that's on your staging site and push it to the live site and you've got the same process you can do another circular workflow there or from the live site back to these guys and then you can prevent these guys from going to the live site and you can implement for instance a switch on your live site that says I'm turning the admin off and then they can't make changes and that's very easy to do because we have a central API through which everything flows and so to me that would be an ideal workflow it's a workflow that's exactly like your code workflow but still enables the UI stuff that really makes Drupal the popular system that it is and that's our goal from the beginning for someone who's in a simple site like they have a local host and a live site they can do the same thing they can just FTP files around it's the same process it's just a slightly different workflow and in reality it's actually a much more similar workflow to what those kinds of users are used to in Dreamweaver they write a bunch of HTML code and they push a bunch of files up and it's ready to go and actually it'll make a ton of sense really? I was wondering what you think the future of features will be I've actually talked to those guys a lot and what the future of features will really be is that it'll just become a UI for configuration management it may present some more advanced features like I don't have the ability to group pieces of configuration and only push those so they may wrap around configuration but I still do here is the view and the image style and the content type I need for a photo gallery and distribute it I don't have anything like that they may also implement some things that we're not implementing but will hopefully be possible to do things like here's a diff of the configuration on your disk versus what's in the live site or even better here's a diff of what's on your site versus what was on your live site the last time you did an import and you know maybe even do a thing like I want to take this piece of configuration and make it live but not this one you know there's all sorts of really cool things that as we sit around and talk about could be enabled if we had time to do them and you know a lot of that advanced stuff I don't really think is necessarily appropriate for core anyways but we're trying to make sure that the APIs have worked so that's the kind of thing I think features will be good for in the end what will happen is that features module will get like 80% smaller because all of the code that they're doing that's one-off implementations of stuff that's in core or supporting exportables or things like this can just go away anybody else great thanks for coming watch it please it occurred to me quite recently about the fact how all of this is going to translate about the update hookup.n functions and how stuff that are currently accessed in dbtables stored in dbtables config that have a predetermined schema since they are in SQL tables so right now we have a kind of data part of the presentation where we have those structured files without a schema and so that this thing about we currently are not supposed to invoke API functions within hookup.n I was not completely sure how this maps to the new system and how we are going to manage the fact that we are changing the storage format for a given config thingy or to I need to change a setting across all text field types definitions that currently exist on the site but I'm not supposed to call the regular API functions to do that so I'm not sure it's not clear in my mind how this maps to the new formulation of how config is stored I mean we're not going to have schemas so a lot of things to get validated by the database right now won't be and if they are important to you you're going to have to do it yourself and as far as what best practice is for implementing updates is going to be I think that's something we're going to have to work through and it relates back to the stuff that I was talking about versioning if you update your module in a way that changes the schema of your underlying files you are absolutely going to have to go through and find all of those files and update them and reshape them by hand that's right possibly depending on how your API functions are designed possibly outside of those and since you're the module owner and you know enough to do that it's okay right we do that with the database sometimes too right you know that's something we're just going to have to work out I think and if we and if we encounter problems as we're working through we'll have to make changes we'll have to update the APIs yeah yeah right right right right right right right or something like that I mean maybe you want to hire them because there are things like for instance when I delete an image style we've got that option to go back to all of the fields that implement the image style and change them to things so it's like either you can do it by hand or you can call the API that does it automatically but then if that API does things that you don't want to I mean you know we're going to have to work that stuff out it's a little less structured obviously but yeah that's probably true another question about deploys how do you see downtime being impacted by this like for example right now when you deploy code there is a time between when the code is on the server and you run updates and other things like that where it's in an unstable state we have modules that are not loaded in the device so do you see this as eliminating that or the same or how do you see that happening it's going to be the same I mean you know you can't change changing a field changes the underlying structure of your database right and anything that changes the underlying structure of your database and then has to go through and modify the data that is there is going to take time and in that time your system is going to be way around that and it's not like we're changing the field system to fix that problem so there have been discussions about whether or not when we run this system we should force your site into maintenance mode for instance most people don't like that idea and I think our best thing to do is to focus on making the actual updates run as quickly and performantly as possible and anything that can't be to run it into the queue system as long as your site can run and it can run in the background for things like field updates like the delete stuff and stuff like that and focus on it that way and you know for simple stuff it'll be just like running updates now your site will be fine as the simple stuff goes or maybe be slightly weird until you clear cash or something like that but overall I don't see the situation much different than the way it is now as far as that goes great thanks a lot everybody