 So, rauwhai gau i te topiqa, te problema, heistiri i web-applications, trends, existing efforts to assist with packaging web applications, continuing problems in spite of all of these fine efforts, and then I want to have quite a lot of time for discussion, so I don't want to stand up here for too long actually talking, and I want to try and get some of you guys to have some good ideas as well, because there isn't enough. So, the problem, I guess, is many modern web applications are built using, many modern applications are built using web technologies. This is a problem because web technologies don't define any standards whatsoever. They are written in a wide range of languages. The standards are, they don't run on your computer, I guess, and they use HTML, HTTP to communicate, mostly. So, yeah, approximately no useful standards give or take. The history, in the beginning, we wrote our applications with switches, and then we moved up to having serial terminals, and serial terminals worked quite well in a lot of ways because when you wrote your computer on a serial terminal, the computer, you only had one computer to deal with, everything happened there. The terminal had a defined, structured interface for interacting with it, and we kind of got used to that, the computers got bigger and we needed them to do more, and it wasn't that pretty. So, people came up with client-server architectures where we hived off all the display processing to the client end, and the server was left doing the grunt work, and that was kind of prettier for the people using them and extremely, extremely uglier for the people writing them because we ended up with so many standards for communication and layout in those applications, and we still had a very tight coupling between the client side, in many cases, and the operating system, or the libraries on that operating system. So, in due course, Web 1.x came along and we started to see web applications. In fact, the web was around for quite a while before we started to really see web applications, but eventually they came and they worked quite well, but they still didn't have the same interactiveness and power of the client-server approaches. So, people came up with Web 2.x, as it's called these days, which obviously gives you a lot more power, a lot more prettiness, shiny, but it's a lot harder to package. And so, these are the trends that I see at the moment in terms of web applications. The Web 2.x is definitely here. There are an increasing number of applications that are arriving for the sort of method of providing an interface to users to do stuff. They're not going away. They depend a large measure on JavaScript libraries and those JavaScript libraries seem to be seeing some sort of voting with your feet trends to choosing particular ones. So, some are surviving and some are going away. So, there's some standards emerging, I guess, but they're still not clear, certainly not clear to me. These are the existing efforts within Debian to try and define how to package things. So, how many of you use DB Comfort Common? That's a few. It's not too bad. And it seems to be a pretty good standard. Would you? Is it difficult to use? Do you find it difficult to use? No. No? OK, good. I think that's probably the best thing that we have at the moment in Debian. And it would be nice if we could move it upstream as well, but I can't see that happening. It's just too broad. The web applications policy, how many people have read that one? Neil, who wrote it, at least partly. Which is a fine effort that was started, what, 2005? Yeah. And is still draft and was last worked on in... Well, 2006, according to the document itself. But, yeah. It really needs more people to understand its existence and I think it needs a big push to get it approved as some sort of standard policy and move it out of that draft status. Because it's a good document. It says very good things. It explains what you should do with web applications, where all your files should go and pretty much why. So, I mean, I'm standing up here today, largely to publicise the existence of that. Something that's emerged recently as well is improvements in JavaScript packaging. Anybody here maintain any JavaScript packages or depend on any JavaScript packages with their stuff? Yeah. So, how do you find that the existing JavaScript packages work okay? Because a lot of problems that I see with upstream in particular is that they include chunks of libraries from everywhere, you know, bits of code that you've got to carve out with the axe. And JavaScript is one of those things that's even more complicated because it, again, you're back in this client-server thing where the JavaScript runs on, God knows, you know, and the other code runs here and they have to mesh. So, if your application depends on a particular version of a particular JavaScript, you really need to have versioned library dependencies to do that again. Well, I'm not sure that they're happening, but what seems to be happening more is that it just gets included directly in the package in the one place. Yeah. And so, continuing problems that I see are this lack of publicity regarding web applications policy, the need for setting that as a standard for official and FHS compliance, which is part of that. Applications putting their files in slash opt or user local or whatever. It's just, you know, it doesn't happen with official Debian packages, I guess, but certainly upstream wants to do it a lot. So, yeah. I guess that's kind of all I really have to say is I'd like to go on to discussion. Well, I did want to go on to discussion. And to help that, I'll take a leaf out of Don's book and set up a gobby session there. So, if you want to join the gobby session, do I need a bigger font for the... OK, let's see if I can... My mouse point is not big enough. How's that? Anybody on the ISC saying that's all right? OK. So, does anybody want to... Manoj, thank you. Do you want to get a microphone? I missed it, but I haven't seen any requests about making the web app policy or the JavaScript packaging show up on the policy mailing list. So, if you have put it up there and I missed it, I apologise. I wasn't responsible for the web application policy. It's Neil there who's hiding at the moment. And I don't believe that there has been any official request for it. I think that it got to a point where the authors saw some deficiency in what they had and they were seeking perfection. So many of us have a tendency to do. That would be a policy mailing list. Maybe that's why they didn't feel they fitted in there. One of the things that I'm trying to improve in the policy process is helping people create draft policy for future inclusion in technical policy, even if the current form isn't good enough. To include in technical policy some idea of time changes. The TDep stuff is currently not something that we want, but Lenny plus 2 it will be mandatory. It would be nice if you could introduce it in earlier versions of policies so that people have, it gets wider visibility and people have some idea of what's coming up. So, if we can co-operate on getting this in we might help my new financial change policy update mechanism talk. If we can use the web app policy as a getting pick to get new ideas into the WN technical policy as well. Yeah, so I think that's good and I guess that's the first major point is that we should submit what we've got to the policy mailing list. If somebody wants to note that. Anybody else have something they want to add? I see somebody talking about JavaScript common there. Neil, you want to? There's a microphone. Great, thanks. One of the main, we did consider adding the web apps policy manual not only as a draft but tried to get it integrated with full policy. One of the main blockers we saw for that was the use of the helper similar to dbconfig common. I believe it was, Sean Finney was working on a web app common framework so you could use this to install the different web apps in different with different web servers and with different hosting environments so you could create virtual servers quite easily and you could use one config sorry, one install in different configs for a virtual host and things. I believe that was quite a bit of work being done on that but that sort of stalled. We were waiting for that to come to the forefront before trying to push with the policy because we realised that something is needed to help register all these web apps with the web servers in a standard way. I think that's good but perhaps policy should lead the development that the policy should settle before we write the utilities around implementing it in an automated manner. Really my joke about DH make web app is because it's impossible without having a policy and the web app's common is great and a noble effort but it hasn't made it into Leni and really we need to get it out there. Yes, Andrew, I was going to point out that this isn't the first time we've had a suggestion that it might be a good idea for policy to lead implementation but that really is sort of a complete break in the tradition of the project in the sense that to some extent policy has always been a trailing process that the expectation was that people really would sort of prototype things implement them, the better mousetrap would attract more mice and it would eventually have in effect a self-emergent this is the best practice for doing this therefore so while I completely understand the sentiment that says it sort of seems weird to go write a bunch of utilities and code a bunch of automation until we have some agreement on how that should work I think we have to be a little careful about describing that as policy in the sort of Debian policy document context of the word policy because it would be sort of backwards from the way expected things to emerge and evolve Right, I've seen policy from what I can see describes where files should go and so on and not necessarily how they should get there Manoj? Traditionally we have always wanted a reference implementation before you codify things in policy Unfortunately while I still think that is a good idea unfortunately it has led to several efforts trolling because it is a chicken and egg issue Sometimes we need some direction to be decided on before you put in more effort in doing a reference implementation and this is one of the things that I want to address in the policy update mechanisms going forward We need to create something which is in between the wild woolly no direction and the retin stone technical policy, you violate that and you get a RC bug on you situation This is something that I will be talking about on Friday I believe Oh my goodness, it's tomorrow So I would appreciate it if you could come to the talk and we could maybe hammer out some of the details about what needs to go into that updated process in order to do things like this We need some direction and yet we need to decouple the development from actual releases Don't follow this and your package gets thrown out It's too early in the web app policy development to go for that kind of strictness and yet we need some place for people to come together Maybe what you say Bdale about accepting the best practices that we see out there There definitely are best practices in packaging web applications I think in the JavaScript common package for example is one of those and there are use of DB conflict common and so on Those are best practices that are there There's plenty of stuff that we can look at and so well it's best practice and let's document it and the web apps policy document the draft that's out there seems to me to document best practice pretty darn well really It just needs to be ratified in some way to be made more official Manoj has this You got the mic right You got the mic now I think you're absolutely right A good take on this which is that there is great value in having some mechanism for us to come to some convergence of opinion agreement and to drive sort of forward in a consistent way It's that sort of final step of putting the seal of approval on it saying yes this is the policy and this is the way it will be done that I want to make sure we don't leap to too quickly versus trying to of getting people to converge and move towards that ultimate objective But if the document's been around for three years now and only not submitted, no but even without that submission nobody's seen any good reason for changing it in the last two years and maybe that's just because they got bored and stopped looking but it's I think if we submit what's there policy mailing list that then we'll get feedback there and can modify it for some things that have changed in the environment in the last couple of years and it should Yeah It should be good In some ways you guys are the domain experts So the policy mailing list will tend to defer to you because you guys are the ones who are actually implementing the way back and if you have come across something that is a best practice it's likely to be accepted As long as there is cognizance of the fact that despite what the Pythonista say there is more than one way to do it So as long as we leave room for diversity in the ecosystem I don't think there will be a problem in fast tracking we probably can't get it into the learning policy No So learning plus one shouldn't be an issue So who would be interested in helping out to get this and maybe I can put their name up in there I'll sort of take some responsibility for pushing it through but if anybody else wants to help out in reviewing the current policy let's move forward Thanks Neil, you can put your name in there especially as you're already down as one of the authors Anything else anybody wants to talk about about web applications Otherwise this is a very short talk Tim Wait for both I won't do this in stereo So you made the joke about DH make web app and I was thinking about this and actually a lot of these web apps are going to be based on some framework so for instance a lot of them will be Django apps and have a very consistent structure Is it a possibility that once we've got all this policy in place we could put together say DH make Django and it will automatically package up your Django application for you or something like that or in pearl there's catalyst framework and Ruby gems so on We're going to hear about Ruby gems this afternoon I believe and yes and I don't know if that could sort of be mapped into some sort of web app thing maybe that would be a bit silly but we could get some sort of way to that goal at least for apps which are consistent which are based on a framework I think there's hope for that OK I guess it's not very contentious Thanks