 Felly, rydym wedi bod ni yn gweld i wefbapt ganwethaf a thisai bod yn gwneud i'r fath o'r cyflwyno. Rwy'n cael ei wneud i'r wneud i wefbapt, ond mae'n gweithio ar y gwnaeth. Felly, maen nhw'n gwneud i wefbapt yn cael ei wneud i wefbapt. So, first of all, what is a web app? Well, we in the group have to find a web app as something that a package or a group of packages that has access to a HGPP, or a server, or applications that run on a server, so you also include things like a server and various Apache modules which are still essentially web apps. Our aim in the team web apps company is to produce a standards document which we hope to integrate into policy as a way of a best practice procedure for how to package a web app that's secure, portable, allows upgrades at the moment because nothing does. We also introduce packaging manual, how best to do this, with examples, and help for applications. So, one-term goals, quite simply, is to have all packages combined. This is very important because if we don't have all packages combined then there will still be security issues and we need us to look at security issues in web apps in particular. Basically, if we get all packages combined, it's a lot less work for us. It should be a policy, best practice, so whenever anyone packages into a web app, then they refer to the documentation we've written. And, as I mentioned earlier, the help for applications. So, they should be easy hooks into maintainers scripts so that people will be able to install and register web apps easily. Current issues with web apps include problems being compliant with the FHS, peer-to-pea libraries at the moment don't really have any standards to follow. As you mentioned, this isn't in order of priority or anything, but it's just a general list which we brought up together. Database interaction. So, does a web app register with a database? How does it do that? What happens if the database is on a different box? What about if the database is offline? And, dealing with a web server? Does it need to, for example, register a module with a web server? And, which web server? So, move on first to the FHS. Most web applications have a single folder in school. Now, this is done by upstream, so it's very, very easy for the NJZ. Just copy all the files in here to a web-accessible directory, and everything works. But then that causes no answer problems for us. Conflict files and included libraries are normally within the single folder, so it's part of the web route. This obviously has security issues. If you have a file within the web route, the web server can access it, and it makes it a lot harder to attack a box if it's outside. The same for included libraries. You don't want some functions being public that are available. Again, template files, for example, skins, plugins or whatever. The admit local administrator will or may want to change those. If it's all within the web route, when it gets to upgrade time, it's going to cause an absolute nightmare. The other problem with web apps at the moment is that many of them use hardcoded paths, so they, which also instantly search about layout of the file system, expect things to be in user-level, for example. They expect things to slash SRV to exist. I mean, they're all hardcoded all over the place. Even this day, simply a bug in that application is built. Package for the bin? I mean, do we really need quality to say, don't write buggy apps? Yes, ideally, because the amount of ones that don't write buggy apps. But that's the quality that should be something that we do anyway. There's a lot of gray areas. We have to tell people what a bug is. Exactly. If you don't have a policy, how do you know if that's exactly a bug? What is a bug? Depending on anything in user local, for a database package, it's a bug. We don't need any policy about these things, don't write buggy codes. I'm just saying that we are kind of expanding the scope of this document to a point where it might not fit into general technical policy. Best practices might be the best re-corpers towards the developers reference. I didn't mean to call the big into the trend. I just wanted to raise the point that we might be overreaching the error. The first and foremost role is to make a best package of the document. After that is stabilized and solidified, and we have people actually adhering to it, and the tools are in place to help them. Best practices you can't force people to adhere to. I think we need to separate one of these two things. There has to be policy that packages must follow, and that has to be fairly minimal, and you don't define how people do things. You define what must be done. The piece about things not being accessible under the web server rule, that's a good policy. Some of the other things are a little bit more fluffy. If you could separate these out and perverse them, this part of the document is going to go into the developers reference and best practices that application ought to follow. And this part, if you don't follow this, your package goes out of testing and will not be released, because that is what going into policy means. Not all of these things would mean that things should be thrown out of the web. So if we can start off thinking about what you've got in your web app thrown out of the web, and what else is good practice that should be in the developers reference in Devian or any other help of packages that will come up with it. Yes, and in fact we have sent emails to Devian policy on multiple occasions asking for comment on this. Unfortunately, Devian policy, you're far better off if you come up with something, and then ask people to critique it, then you're asking for guidance that you're trying to do. That's what this has been about. Sorry that I didn't comment earlier, but this is my feedback as well. Certainly any time anyone has any questions or comments, they're more than welcome. This is sort of the end so we can move this on. Sorry where was I? Yes, another potential problem that web apps have is using persistent caches. They can have need files just within the web route because they don't know where anything else is. So potential solutions would be strict FHS compliance. Conflict files go in etc. Caches don't hang around where the hell you want to put it or anywhere you want to put it. And we've got quite a large section of policy of basically, well sorry, we're calling it policy now. Sorry, quite a large portion of the web apps best practice document. On where to put folders, what permissions they should be, which we should probably put into best practice, and items like that. What I'd like to see is according to my truth tales, and I can see a lot of variance in making that. We're going to put these things under, something under far and something new to share. Well also as soon as we truth the web apps can be a work. Yes, we could say the same about many other applications. It's still out to create the directory that's in line with something. Yes, our policy should make it easy to assume this. Ok, that's definitely the point is, if we have a policy stating precisely where the files go and the FHS go, then we have a script to help to create the FHS route afterwards. So this problem does not go away, but we have a solution for it. Ok, we're just going to briefly touch on the HV boundaries, because we haven't gone very far with it at the moment. People are generally creating the HV boundaries in the same way, but no one's really sure what it's got to do. So we are doing a short section of the HV boundaries on how to name PHP packages, which is a large one, because there is PHP somewhere in the module name, PHP in the number module name, or PHP in the module name, and there isn't really any co-gill or anything like that. Also we hope to deal with how PHP boundaries register themselves with PHP. For this, there is a, what we call in policy, best practice on how to create PHP library packages and PHP modules. That's very much in the other stage. We've got the fundamentals, but not much more. There's lots of to do with that. There's also recently been a DHMake PHP package. Now that contains DHMake Pair and DHMake Teckle, which can be used to pull packages straight from Teckle Pair, which are PHP's equivalent of C-Panel, for example, and can pull packages from there. Problems with database integration, with a web app. Top there is the URL for the DB app policy, which was written quite some time ago, I think, really now. Problems include offline copy. What do you do if the web server is offline when you come to install a great package? Normally with a web app, it would just fail completely. Now, that may not be the best case for a DB app package. We want to be able to handle that with the use of the unit. Use of permissions would be an example of a administrator may not want the web server to have grant access, create access on the database. The administrator may not want the web server to have access on the database to create a database, just to read and write an update. Are we talking mostly about PHP-based web apps? Because some of these things, not seem to apply to only web apps, I wasn't using Ruby on Rails. They have different set of problems for their root, but it's very tightly integrated with the database. Most of the time, they don't go under the web root, they just redirect using empty access to go somewhere outside. I was just wondering if there is somebody on the web app team who is familiar with Ruby on Rails, and can represent the Ruby community while this document is being created. I'm not sure at the moment. And all the parallels are also the turbogears. You know, the vital number is popular and developed, right? Which also has its own clerks. We'll try to design this to be as agnostic as possible. So it's not very ready to create a web server. Maybe we should extend the invitations to the package maintainer of the Rails package. Because even though I'm dabbled with Rails, I'm definitely not an expert. And maybe the Rails package maintainer should be invited. See now, Sean tried to get some package maintainers involved, but we didn't really get them. At one point, we sent emails out to various programming language package maintainers and web server databases for package maintainers. That was some time ago. Someone came back to us that was doing it. I guess it could be a little longer. Traditionally, what works best is writing a draft as you understand it, sending it as a proposal for policy and then having all those package maintainers coming in screaming. Can we have one more step, please, before you send me forward to policy? Just send something to the Rails slides. I know that you have tried them once, but if you could please just... It's not just the Rails guys, it's the Flone guys, it's the Mason guys, it's the... Just send it, grab the constituency and send me an email before moving on to policy. They might feel they're being hit on the head with their fake accomplice. You have to see the proposal ready to go. Regarding Rails, it seems like Rails isn't a web app, it's a framework. So you can use Rails to create any sort of thread that you want. That seems like it's not an issue with the package maintainer and that stuff. It feels like it's more of an issue with Rails in general. I think you should get the Rails package you're in here to see. The primary purpose of Rails is to write a web app. Yeah, I know. And so the specific web apps written with Rails, Ruby has this thing. They have this thing about convention, not configuration. So you'll find that most web apps written on Rails are going to form the de facto conventions. So if you can get the Rails people to have input and maybe add on sections which are specific for web apps written for Rails, we might come out with a bit of a problem. And I'm sure the thing applies to no one then. The other packages that you mentioned that I have no idea about. Yeah, so we're trying to be as agnostic as possible. Fortunately, most of these problems on PHP packages, basically, because they have happened to be reversed with... Upgrades are a problem with database integration, because very often it's the case that upgrades between different package versions also due to the fact that it's quite heavy and they can fail as well. And I do a video synchronisation of languages as well. Some languages are sensible and maintain double-edged version information and some languages expect the database to look like this before it starts and to look like them and thems and don't you? Yeah, some of these added users, permissions again, what happens if you have multiple databases that you want to configure this with, what some parts here, some parts there, it's all a bit heavy. Now for this we have a solution like the DB conflict common package. It's already in unstable and edge, I believe. It's being used. It's a framework that basically register an application for databases and provide you, obviously, a great table to update it. You can do various things like that. That's a very specific... Two more packages. Yeah. That's the variant for database. Is there a documentation for DB apps? Yes. I have looked on the web page, there was a green system, so if you like this. The documentation has been... How long ago was this with the release? A few months. Well, the documentation should be updated on time. It could be updated on time. We'll talk more about the actual documentation now. Okay, now the other problem is how does web update on the web server? First, which web server? There's 16 in DB apps, hopefully, not counting the duration. So, you also have, instead of, say, just a passion, you've got a passion SSL, a passion code, and then a passion 2. Not counting the 16 separate projects which we have to deal with so now. Registering involves making content accessible. Possibly, we started a web server group, David, and how should the web app deal with this? Should it deal with postings? Should it just drop things in a conflict directory? Also, we have problems with v-hosting, which basically means virtual hosting. You have multiple URLs, a point of assembly to code, and creating different conflicts for the web servers and indeed the applications themselves within that. Another problem is that there's many applications used and work-based config created to them. So, your login would get to installed or whatever and you're putting all your details there. Now, that would be suboptimal for Debian, I believe, simply due to the way that you want something just running and you could have a long interactive front-end and you don't want to actually go to a URL and put in all your details there. Now, the solution for this one is the web apps form package. This is almost finished. For this bit, I'll hand over the check to you, Sean, to talk to you about this and see how it's the best process you've made in it. Okay. Yeah, let's go over both of these in abstract. I'll show you actually in use and practice. These have been my pet projects in maybe a year or two. From a very abstract perspective, the goals are for these packages to work by consolidating code. Anyone who's looked at more than two or three web applications that actually try to do any kind of automatic configuration will notice that there's very significant amounts of code that are duplicated. Within all of this duplicated code are bugs. Unfortunately, the bugs are not duplicated. They're all unique to each specific package. Often, the features provided by these packages, automated assistance, are not fully developed in addition to being bugged. Sometimes they're not fully developed. Sometimes they're not fully flexible. Sometimes they do things that they really, really ought not to do like editing the configuration files of other packages, taking kind of the restarting servers, et cetera. The goal of these two packages is to consolidate the code that all of these packages would use into a single framework. Consolidate the translations of the DevConf templates so that there's a single set of DevConf templates that all of these packages can use so that the poor translators don't have to basically translate what's essentially the same message but just a plenty of different in 70, 80, 90 different packages and instead, they can translate one set of DevConf templates which then will automatically propagate to all the packages that use these frameworks. And then ideally, it will also consolidate all the bugs so that the bugs that do occur are in one place and when they're fixed, they're fixed for all the packages that use this framework. They work by providing hooks for the maintainerscripts. So, basically, in each maintainerscript, the package will insert a couple of lines that basically source a shell script library and call function that will then do what needs to be done at that stage in the installation. And then, often, a problem with developing all these features and providing these tiny little hooks is often one package will need to do something slightly different than another package. So, there are certain features that are overriding just by setting a few variables before you call the function that does what it does. Obviously, no automatic system will be feature-complete for everyone's needs but the idea is to be as flexible as possible for all the conceivable needs that we can figure out. The design principles of these is to provide consistent policy-compliant behavior that adheres to certainly, first and foremost, to the existing data policy but also to the best practices, documents that we've been drafting up for the web applications and gateway service. Another design principle is that the packages should only have to insert a very minimal amount of code into their maintainerscripts which will reduce the theoretical possibility that six months from now we've realized that, oh no, we really need them to say something else in their maintainerscript. So, please all you guys rebuild your packages doing it this way instead. It also makes it easier for the package. Obviously, a lot of people, if you provide a half of these resistance that's really easy for them to follow that, accomplishes what they want. A lot of people will end up doing that. Another design principle is that the local admin should always have the ability to opt out of any assistance that we provide because it's quite possible that they know something we don't and we shouldn't try to be too helpful because often you can end up with some pretty bad problems when they happen. So, another fundamental design principle is that we're trying to be as fast as possible to both the packager who's packaging the application as well as the local administrator who's installing the application. Okay, so the package is in action. So, included in both the db2fig common package and the web apps common package, there's an example of sub directory. If you install the package, it's a user shared doc db2fig common slash example is the same thing for web apps and you can build these source packages and install them to see how they work. You can look at the source package to see how they actually do what they do. I guess at this point I'll actually show you how it's shared. Now, it's there. It's there. So, how do these do? Use an extra. It's okay. You can click on the camera also. Just run extra. Repeat. Have extra. This laptop's a little slow, doesn't like... ...confrigunder鼱r ar ymysg wneud atriacol Samsung. Rhwng am y dydd ymlaen i'r parwys. Felly y gallwn yng ngynghwm ar y salogau. Yn y tîm ymweliadau, gan ystod o'i cyntaf Llywodraeth... ...yna'r perwyr yma? Mae'r ffordd mae'n rôl ystod... Mae'n hoffa. Mae ymddirwr trafodaeth ar y hiphwil, pan mae'r ddau hostrach mae'r hydrach. Ond ychydig yma... ..es yw chyrhaf i'r hoffa'r perwylliant yma? First and foremost, it asks, do you want assistance? You can say no and then it will pretend it was never there, but then it wouldn't be a great example. So in this case, you're presented with your past, what virtual host would you like to configure this for? Global is just the default, whatever your default server is, so I'll use that. Then it will ask, what's the name of the subdirectory under which you want this website to be available? You can provide a nested subdirectory. In this case, you can provide an empty name in which case it will actually be the document group of that virtual host. In this case, it will just stay for the default, which is the package name. Then it will ask about what web servers you want to configure. So let's actually do this without a warning. Now it's asking, this application uses a database, so would you like assistance in the centre of the database? Sure. It's a MySQL application, so it's asking MySQL specific questions. How do you want to connect to your MySQL server? You select a unique socket, it's going to try to talk to the MySQL server a little bit more. If you select TCPIP, you'll get options about connecting to remote servers. The administrative user group password is TCPIP. We've got a MySQL user name that defaults to being based off of the package name. You enter a password for the user, then the name of the database for the application you create again is based off of the package name by default. Then you need to reload some servers. Here's your chance to avoid doing that if you want. Now it's configured with web servers, setting up the database, and it's done. Now I'm going to go over to Firefox and it's set up. I've just had some stuff in there. It's a simple PHP page that does some database queries so you can actually see what the database is set up. That's the package in action. There's also another package which shows an experimental feature supporting setting up multiple instances at all. I guess everything's experimental at this point. An extra experimental feature which shows it supporting multiple instances installed at the same time. So you can use the same installation, you can use the same package and configure it so that it can be accessible for multiple directories with different configurations and different databases. So if you were, say, someone providing web mail to different organizations, you could install the same web mail package under different locations and use the same package to set the configurations and set the databases. I won't bother actually showing that in action because I think we're going to take a little bit more time than expected. But I do want to show you basically just how this works. So I'm here in the source package for what we just saw. First of all, the text and the questions. I think they really, really need some usability work because they couldn't be understandable in short lines. You have to really read into it to understand them. And the second one about multicosting, usually web service providers, they could have thousands of clients and they could have hundreds of web apps. And that user scenario, they want to install the package once and not have it activated in post install. And instead they want to activate and configure the package. Then you just say no and it puts that? Yes. Wait. They want to configure, activate or deactivate packages to specific users, to specific records afterwards. That would be perfect example of using the same interface that you have to hear or direct command by interface. Asking the same questions but as a separate executable that you run afterwards after the package is installed. But they've got a thousand users and they want to take one active package and use a number 55. If we install it for everybody, all thousand, but we only want to configure a number 55, you don't want to go to the active executable and try to configure all thousand users all at once. So if you had something in a script that used DevCon post installation to ask the same questions and tap into whatever instance I've already been providing, I think you might fall the fall of doing this thing if you're using DevCon for the registry in any answer. But you're not. No, I'm just looking at everything as I was looking. Well, one of the sort of items on my mention to do with this is possibly exporting some of this functionality to command line programs. But first and foremost, it's going to be scripted. It's going to be scripted. Yeah, it's going to be. But you get working in this score instance and use and see what the problems are as it grows around. Right. And you try to do the whole thing and you can finish. The primary design goal is to tie this as closely as possible with the actual package installation process so that when somebody actually installs a package, they don't actually have to know about any arcane command line programs that my system uses. They don't have to know about. Ideally, they don't even have to know a whole lot about the use and resins of Apache or my simple or postgres configuration. They can just install the package. It configures it to the web server. It sets up the database. Remove the package. It reconfigures it to the web server. Remove the database. Reconfigure the package. You can change the settings for how it's installed on the server. So you could, for example, if you wanted to add installation time, say you set it up for three virtual instances running off the same thing, and then later on you decided, oh, I want to deactivate one and I want to set it up. You can actually just do that by reconfiguring the package. But all that asks questions for all the three user costs. It will, if you like, after we've gone through everything, I can actually show you what I have in place right now with the multiple host support. It's a tiny bit buggy right now, but it actually works enough that I can actually show you how power works. You basically present it with a list of contributing instances and you can deselect from that list and it will remove them where you can say how much you think you're doing. And it will then only ask you questions for that instance. But is that the reconfiguration then? Yes. Quite fit the definition of the difficulty reconfigure then, because you're supposed to get the same question, the same process like you were just installing the package for the first time. Oh boy, I see what you're saying. Well, basically what happens is it precedes all the depth-configuration questions with the information that is stored in the configuration files on the system. And you could, sorry? I'm so excited. If you reconfigure the package and didn't provide any additional information, no changes would be made to the system. So it would be ideal. If you chose to remove an instance, it would then remove the instance because it was specifically told it to you. If you chose to add an instance, it would add an instance because it was specifically told it to you. But if you say reconfigured it with a non-interactive front-end, there would be no difference at all. The idea is to make it behave as much in line with the package installation process as possible so that it's consistent here and won't drive administrators crazy by being confident with the same questions over and over. This might be a stupid question. I understand it. It does not on me that the two applications you have talked about are mostly dealing with installation and dealing with how to integrate with a web server and the database. I think that these are useful beyond just web apps. I have got things that need to talk to web servers and need to talk to databases and they are not. There is no reason to introduce DB Conflict common for that. It is a separate application. DB Conflict common is different from web applications. Maybe we should advertise it. Well, in fact, there are a few applications that use DB Conflict that are not web applications. If I wanted to take pieces of these applications that you created, but I don't really want to talk to either web servers or databases and just like the way you ask a question and presenting me with lists of examples. I'm thinking of AC Linux actually. I've got a lot of AC Linux policies. They're confronted so that administrators can choose the policy and I see what everything that I need. If I just need to throw the web server in the database, I'll give it a throw. It's like DB Conflict, it's AC Linux. So, can I take bits and pieces of these two applications and use it for a long time? No, it's too chaos. I'm not sure exactly. You have written a lot of utility functions that deal with their point of deal with gathering information from the disk. And presenting the user with choice. You figure out how many web servers I installed. I need to figure out how many policies are currently present on the system. You say if you want to talk to web server A or web server B, you want to... This way, where do you want to place your things? For me, I can obey you because in strict policy, you want just a base on the extended version. And that I do get by using a derivative. You've got utility functions that other people can use. Maybe you should update DevCon for that. I think quite your time. If you want to update app dealings, that's fine. It's not the instant. Yeah, it's only cheddar cheese and wine afterwards. How many applications have already used DB Conflict as compared to the already available? 21. I just looked right here. In the very small font, I typed it to WC. Yeah, but compared to the many that we have in Davion... Compared to the what? How many applications we have using DB configuration in Davion already? I would say that DB Conflict is actually a fairly young package. I've been working on it for some time, but I don't think it's been generally useful, stable and helpful package, except maybe in the past year. I haven't been going out my way trying to badger people to using it because I've been quite busy with basically talking with people who are coming to me saying, I want to use this, but I need this extra feature. So when I work, I think about it, and then in most cases I provide that feature so that they can actually do it. I've been so busy with that I haven't bothered to reach out and try and bring anyone in. I was actually surprised to find out that there were 20 more people. When I was asked me a couple of days ago, how many were you using? I was like, oh maybe six or seven or something like that. I went and looked right here and said, oh wow. I actually have done two of them, but I see that not many people are using that, so maybe you need to sponsor that between me. I was in the middle of this. It's one of the reasons that it's bought. It's one of the reasons to make policy draft for using it. So more comments are coming in and more specific people are looking at it. This is a constantly evolving process. One of the things with policy is that there is a chicken to make thing. You can't just write down something in stone and say, oh it's policy and I expect people to start following it. I mean, not only that, but you can't... You've come a good start in that approach. We also map with the draft. The idea is that all of these are developed in parallel. When we come up with a draft that says, this is the way we think things ought to be, then we come up with a code so that people can do those things the way we think they ought to be done. They sort of feed back into each other because sometimes you realize, oh we missed, oh we need to consider this one thing or maybe we were too short-sighted to this other thing. So they feed back into each other a lot. I think this is the ideal way to get things fast-drafted in policy. Yes. Okay, well, are we... Okay, so now in the road head, basically where things are and where we're going with things, yeah, like Nils said, you can take comms out on this table. It's a natural, you know, it doesn't do any arcing bugs. It will be a natural when it's released. It's used by about 20 packages. Web Apps Common is more of an alpha-state project. Because my own personal resources are limited, I started out very centrally focused on deep version of Common because it was much narrower in scope and something that, as I, as a near mortal, started off in scratch to do. And then what I learned from that, I applied to the Web Apps Common package and that's really where the real work is happening right now. And so, yeah, we'll probably sometime after DevComp will be going into experimental and asking people to just try it out to let us know. I'm trying to say, packages has never been in Devian before. They've no point in going into experimental. They're not going to break anybody. They're just going to be using the new packages and just put it straight into the set. There's no reason. If any current packages want to use this, then they should go into experimental. My fear is that we may end up making some drastic change to this kind of behavior. This is unstable. Yeah, well, my personal method of operations, I don't put stuff in that table unless I feel like it sign off on the job like that. I feel like it should go into unstable because people, you know, you don't want people to go into experimental just because they want less for example. Yeah, and you're not going to damage the existing system. You're not going to impact current users and the people who are writing the application based on what they're developing and they know what they will get when they're running set. The problem is, when you start putting packages to where it's coming to and all the packages maintenance start writing the packages to where it's coming and where it's coming, ends up not being released into Edge. Why not? Well, I'm here, but it's not depending on whether they're packages. Sorry? It's not depending on whether they're packages getting released into Edge. That's the problem. All the version that's currently unstable, the version that's currently Edge do you know any serious ones in the package? Do you know there's anything that will cause data loss for anybody? Not data loss, but there are... Well, I feel it's this is why I say it's... I feel it's mirroring the point where I should present it to the world. It's not quite there yet. This is your package, your decision, but my advice is unless you've understand there are people who need the exposure to this will get especially if you guys want to post this into policy before release Edge. No, I don't know. You don't want the Web Apps policy to be Edge's policy? It would be nice, but I'm not sure the timeline is with us. Yes, from what I've seen I think you guys are far enough ahead. No, probably not. A policy in this way to play at least for Web Apps policy it could make it the deep-in-config common policy. My piece, but also quite questionable because it is not much to understand. Yeah, and not only do we have to have it prepared and presented and agreed upon but then we have to go find all the packages that are doing it and get them fixed. No, this is... It will come in as a recommendation. It doesn't come in as a must. The only packages that choose to use Web Apps common and the deep-in-config common will be policy. You know, policies for packages that choose to use those tools. No, no, no, no. No, no, no. If I'm writing a Web application where do I dump my files? Where do I dump my dash? Where do I put anything? Can you use it a little bit? Whether I put anything to use a local order in the world of WWW that's policy. How is the public press reference? You can get that to the public press reference. That's what's very important. And using the packages currently really long needed. People should be using packages correctly without being hit on the head with the developer's reference. In any case, it would be better if we did this. Yeah, it would be better if we did this. I think the train said and I would think that you guys have a decent chance of getting at least at the recommendation moving into itch. Actually having that on the developer's reference, we don't have already. I've seen it dropped and I think that it would be good to have that on the developer's reference because there's people making Web applications that don't have it too. It's a total mess right now. You said to yourself that it's a mess out there. Something, any guideline is better than that. Any package is better than the mess we have and what you have until October to get all those nasty bugs that will really slow it down. This might be better. OK. Is there a report? Thank you. What next? It's glass zero. This is what we've done up to the present moment in time. We've got this draft currently in practice. Or policy or whatever you want to call it. Is there a next match at the moment? I think you have some policies that you can take it out. Yeah. But Web app's common package which is more or less right now. You can't do the common package but it's already there. We've got this best practice at BHB and not the database which John know not much about. He's actually slightly used now which is good. What we've got to do next is work, well basically on this policy try and get this integrated try and get more people using it and talk to the people who are known and raised and so on. It's trying to get input and try and get these things. Actually if you can get them to be part of the team and you can't post them today but if you can extend them in invitation to have a seat at the table that might any of you may have played it before but I think at this point you'll be able to find more positive response than you did before. So you've got the Web app's common package and you can't become a package without these years of work not only because it makes the package do the right thing but it's also easier. It's much, much easier than having to sort this all out yourself and it also provides a much more standard base for all these packages so now I'm in a blue pot and its database handling is completely handled. And brought to you? Yeah, it sort of works. But if we people usually can't become a package it's going to work and it will work in a standard way so let's do it if they really can't become As we said, the least though is edge plus one If we can get it into edge that's great. That'd be brilliant. It won't be a must rule. It will be a condition in edge. Edge plus one is when we say that we are going to get it going out. So thank you. We would like basically edge plus one for all packages from my dream as long term girls all packages to be compliant everything works and this whole problem which we have at the moment is all nice and clean and sorted out. Does anyone have any comments for anything? We're very in the policy because the policy just stayed where it put things and cleaned things up as hard as the file system or is the policy going to try and enforce people who package web apps to use dvd content content. No, that's looking at the virus. You're only talking about policy but maybe there's obvious references to other things. Men, if I could say that you put packages and thinking in this or something. They'll have their own database in methods, upgrading methods that come from upstream. Which is certainly something we want to preserve. We don't have four seconds. Actor records for example that grades users in the back end. Actor records is totally different unless we can if you have got some kind of a configuration plug-in interface to do the config being actually able to configure grades that actor records based on what they use next but that is something I don't know how modular it is. What language is it that we need? What language? There are all shell scripts in very big shell scripts. In which case it should be possible to load specific things like this is loaded from the script so you can compile the database back end but it doesn't work to any of the normal and none of the military of talking to databases. Do they run under the day? Do they run under Gash? I'm Does Gash support local? The local key word? I'm a bash this. Is this the one thing that it doesn't you know what I'm saying? Is this the one thing that it doesn't support local but then some of the others do? I don't think it's perfect if in the exercise extension. But there is a way for it. You can already use bash It's the first thing. I was just wondering about you. Music is the same language. You should talk about why you need key. There is one thing that I would like to bring up. You said that all this was done by thinking about policy. Edge is going to ship with cylinders on the system and targeted policy installed. Maybe you can turn it on if I can spin down my policy by its level. You guys have come up with a decent pattern for how web application should be present on the disk and the pattern for how this should be. I think we can also come up with a security pattern for Edge on this one which can be part of the document and then the developer applications can create an application which does this you get a default policy. Which goes in there. It means there is a policy generation for web applications. That's right. Complete based automation. I'm doing some of this already in order to be testing for it. It won't require much to do the automatic policy generation. We need to do automatic policy generation for the internet because otherwise we are never going to be able to code 15,000 packages. The truth is web apps are not yet. So it has a version repository. The main list is getting on web apps and a list of them at all. If you go to webapps-com.alib. It's got the drafts on there at the moment. It's got the one which we have for web apps. It's got the PHP 1 and it's got the what. I think it has the dark condition on the actual web apps. Do with DB content comment stuff is people aren't doing it at all. It's not still there. So please join with it help us. We're not speaking already. At the moment it did start a while ago. There's lots of activity and then we've kept on doing work in other people. It's the first ups and downs. I know where you're coming from. We're done with people on the web apps. It's me and James. We've had really good input before. Now again we do get people coming to the web apps and say what should I do? Do you want them at this? Try and do that. Most of us have helped point out errors in all of the drafts. So any help you can give us? It would be great. We just want to start with you. Thank you everybody. Thank you very much for coming home. Thank you.