 so that we can see where Ikiwiki is, where it's going, and just discuss the future and have the problems it has, what it can do, what we can do with it. A pair of models down there, which, the main point is the point of where Ikiwiki is, where it can move, how it did develop, how it really well, the other thing is, basically, there's some issues, some topics that I'd like to talk about, but I'd like to collect topics as well in the course of the meeting so that we can discuss other things. Speaking of general direction and where Ikiwiki is, my impression is that from a very active start, it's now reached a stage where all the things you usually are in a very good work in order. There are plugins for several battle process applications. Most of what's currently active is basically bad fixing, or developing some changes with respect to portability, I think. There's been a recent schedule on micro-ass, like for you, when you see Ikiwiki moving, do you see more movement to come? Do you have a second with Mike? Do you have Mike's idea on it? Do you have Mike's idea on it? Mark? Do you have Mike's idea on it? Mike's idea on it? Yeah, I think so. Yeah, I don't want to start this all over again. I'm very young. Hello? Yeah, thank you. So for those on the stream who might not have heard, Chris, Christian asked me, I guess, where Ikiwiki is going now. I think you're basically right. It's kind of a mature project in a way. It's what, nine years old or something. I don't remember. Kind of, it's in, right now, I kind of think of it as being in not really maintenance mode because we're still actively adding features and stuff that I'm not really actively developing on a day-to-day basis. I'm mostly just merging patches of other people from up with and then fixing the respect reports. And I don't have a lot of time for working on it myself, but I think there's enough other people that it's keeping on with some momentum being developed. As far as where I anticipated going, I personally plan to continue using it as a foreseeable future and keep maintaining it as long as that's going on, but I don't know if I'm gonna be doing some massive like a rewrite or anything like that. I doubt that I would have the time to do something like that, even though it might be interesting. And I'm kind of, I've lost a lot of my pearl hacking abilities because of learning other languages. So I'm kind of, my productivity in pearl has gone way down. So that kind of limits how much time I want to spend on Ikiwiki as far as detailed patch review and coding and that kind of thing. So getting patches into a good state before I look at them is the best thing from my point of view. How many people do you estimate are active around Ikiwiki or is it only you who finally commits the things? Yeah, it's pretty much just me who has final review and commit. There's no particular reason that's the case. That's just how the default kind of works out. But there are Simon McVidi in the UK would be probably the first person I'd happily give a commit that to anytime he wants to. Might assume we haven't really talked about it, but he's made a lot of patches and I trust him pretty much implicitly with anything. If he just signs it off, I just merge it immediately. So he effectively has a commit that. I'd use questions so far from. A slightly mischievous question. So the rewrite in Haskell is off then. Unless I have three to five years that I suddenly don't have something else to work on. One of my pet peeves right now is about localization. We have the wonderful PO plugin that is really, really great. Unfortunately, as soon as you start trying to get something really neat and clean, you hit the templates. And the templates right now are not localized and can't be localized. And also, the templating system is pretty airy. That's one thing that could be worked on. If somebody would like to redo the templating system and could come up with a patch and get it reviewed by a couple of people, I would be happy to swap it out. And as far as translating the templates, I do have a plan to do that. It's basically generate them from a Perl script and then translate the Perl script. So that way you don't have to deal with a special translation layer just for the template system. It's something that somebody needs to work on. I personally don't have an itch regarding translation. So being monolingual. Just so to get a rough impression, are there many people around here who are actually using Qwiki translations? Either. I, for my part, usually have a wiki set up in English on whatever content I have. I have not used the PL plugin before. Is there a way to preview a page with all the wiki links and everything, how it's rendered before committing it? The wiki links are previewed. It's just a few. What is not previewed is things like sidebar thing, but... No, no, no. When I edit the file with my text editor and before committing it, well, if you look at my commit log in Qwiki, it's like I did that page formatting, formatting, formatting link, formatting tag. You can actually run Qwiki without having it committed. If you're speaking of... When you said you're using the editor, I assume you have a local copy and edit it in there? You can just run Qwiki from that source without having committed state? There's also a switch. I forget the name, but it'll dump out. It'll render the page to standard output, just one page. And I think you have to either give it your set up file or it doesn't have all the settings in your set up file, so it's not perfect. With regards to running Qwiki without committing it, that'd be good. There's one issue I had, which I think I have two or three copies of the repository. And because in the tutorial for setting up the site it says that you need to make a gitbar repository there and a working repository here and then where the repository end up and I followed it. But then I ended up basically cargo-culting what was in it. It's not clear to me in the long run what these bits are for, which makes it harder for me to manipulate and maintain. Yes, I thought maybe I can run Qwiki by hand, but then in which repository and maybe do I screw up one repository if I write it in the other or... What can be a little tedious is the paths you have in the set up file. Might be relative paths if you set it up without passing up to the paths. So that's the only thing you have to consider when you're thinking cross repository. Apart from that, there's a bunch of metadata Qwiki collects in the source repository, which is the checked out version. So that's where Qwiki keeps its own stuff as well, which is I think part of the reason why there is the source repository though. You mean the bear repository? No, the regular source tier. That's where there's a .ikwiki, which contains the... All that information is stuff that can be regenerated or downloaded or something. It's nothing that you have to keep a hold of. You can simplify your set up with the... You can get rid of the bear repository if you don't want it and just have one repository local and one remote or something like that. The only reason the walkthrough as you set up the bear repositories because most people, they find it easier to have a bear repository used just because of how Git works, but you can definitely do it the other way and simplify things down. I only have one repository, one coffee on my laptop with repositories. And I run the... I just run a .ikwiki with the set up file and know that it's gonna work on the right repository because like Christian said, I have absolute paths pointing to it. Like you said, I have absolute paths pointing from my set up file, pointing at the right repository to use. How we're getting this is... I've seen Ruby compiler, they have a command like server and then it fires up a server that runs a web server and you can connect and it renders the page it's live so you can actually preview. Is that something that would be very hard to do with the current .ikwiki? Actually, it shouldn't be that hard to do given that there is the option to pipe out the result of rendering a single page to send it out. So you could even implement that stand alone from .ikwiki. Just have a server that requests the pages. I think you would have to have the server either have all the HTML files built and stored somewhere or render them all on the fly and otherwise links wouldn't work. I mean, you could definitely have some kind of a .ikwiki Insta web thing. It's worth thinking about, I haven't really thought about doing it and maybe it's a good idea. I just run a HTTP server on my laptop so then it's one less complication, right? It's one less thing that's different between my preview setup and the production setup. Well, yeah, sure I do because I install, when I run .ikwiki it installs into the directory which is viewed by the, which is served by the web server and I refresh the browser, okay? It doesn't auto refresh but other than that it's live. Maybe I don't understand the goal. Well, the Ruby thing that I've seen is that you save the file and you refresh the browser and you have the rendered version. So with your setup, you still have to call .ikwiki manually to refresh. That's one extra step. An Insta web thing would be interesting because when doing loads of massive edits, if I rebuilt my wiki it would take me about 30 or 40 seconds. So that doesn't quite work for quick turnover of edits. So if there's running wiki as a web server temporarily so it keeps state in memory and only observe and quickly renders as everything ready to render a page quickly for when one page changes that kind of makes sense. So there's a more general problem here with Ikiwiki's scalability to a whole lot of pages and if you're using the Poe plugin like integrity is over here saying mine's really, really slow because Poe is, it runs a lot of third party commands and stuff. But just even if you're just using regular Ikiwiki when you get up to tens or hundreds, I don't know how many thousands of pages you get quite slow just because it has to, every time it's run it reads in the index file and then writes it back out. And that's a completely unoptimized data storage format that has not changed in a long time. And if you switched it to say using SQLite or something and had a proper database you might not even need to run Ikiwiki as a persistent process to get a massive speed increase. And so this is something that is on my long-term to-do list and really needs to happen, I think. I have various people running sites that I'm responsible for that posting comments and things to them just gets quite slow. And trying to deal with that, I'd really like to get there. I just haven't had enough to-its to do it. And if somebody wants to sit down and try to, I mean it's really simple for all code. Right now it just dumps out like basically raw serialized data out to disk and loads it back up and finding a way to convert that to a database would probably, probably someone who knows databases better than I would find it much easier than I would, so. I was looking into, a while ago, looking into adding support for the Malart format Ikiwiki because I think it's really nice format for writing documentation. You can get a lot of good cross-linking for free. MA, double L, ARD. It's the one that GNOME uses now, nowadays. And the problem is that the processor there always operates on the whole directory at once, so it pauses all the pages. And trying to get that to integrate with the PO was pretty difficult because Ikiwiki thinks it can call something for each page and so on, so I don't know if you have an idea how to go about that. It's good fun. It's good fun. It's good fun. It's good fun. It's good fun. Well, it always, since it does all the cross-linking it's always generating all the HTML files from one directory at once, so. In that case the Malart compiler is doing part of the work of Ikiwiki, then you would, the cross-linking that it needs to read the whole directory to do is what you do in Ikiwiki. So, well, I don't know how that works, but I haven't seen Malart, but I just took a note to look at it. But for what you say, if it needs to read the whole directory to do cross-linking, it sounds to me exactly what Ikiwiki is doing. So one file can be read with, and the markup interpreted, and you let Ikiwiki do the cross-linking part. But I don't know what if Malart does this cross-linking in a way different than what Ikiwiki does. So it seems to me that either I have to teach Ikiwiki not to do profile processing in this one directory, or I have to teach the Malart compiler to look at the index file of Ikiwiki. Is that right? Yeah, and to cache the information somewhere. Actually, if this is more about the plain text syntax of Malart, isn't it? Or what is what you like about Malart? Well, the syntax is a pretty simple XML, but what I really like is the way that it connects the different nodes by semantic thing. So I don't know if it makes sense to re-implement all of that in the file. Semantic is part of my building a wish list, by the way. So I had a related question about performance, and I remember somebody asking this some years ago, which is, is a multi-threaded Ikiwiki going to happen ever? See previous comment about re-implementing Ikiwiki in Haskell. I mean, I can't imagine taking the current code base and making and threading it, it just... That was more or less the question. Yeah, maybe there's some hat trick that you could pull with the voids having to deal with locks everywhere, but... I don't have the impression either, so that this is something that's easily possible, short of rewriting half of Ikiwiki. I think it would be possible to maybe thread off rendering, and if you somehow made the render pipeline into an actual pipeline, then maybe you could, you know, thread that in some way, maybe. Well, it depends on what we want to optimize, whether it's plugins that spend much time in the scanning part of the process, whether the index database is regenerated, or whether they spend time actually rendering. Because whatever you render, you have to wait for the index database to be complete because you want to evaluate page specs and that stuff. And that can't be done before you have the complete knowledge of the rest of the system. It might be possible to parallelize the scanning phase, too, using the same kind of a pipeline, but, again, you know, I think a lot of the scanning stuff actually does go in and mungers in general state. I think that's most of the plugins that do things that the scanning phase want to store it for later, and so then you run into the threading issues again. Yeah, yeah. Actually, the thing is that there's no... This would be a massive change in the plugin API, I think the plugins that are available are a big part of what makes Ikiwiki. Okay, so if no more topics come up now, there's one thing I'd like to go over with you, which has... Okay, I think I assembled a list of topics I've been working in Ikiwiki over the past, and turns out there's often the topic of pages having their page title and having their destination file and those things getting mixed up. I think that's partially also because of the history back in the early days, there was a slightly different syntax for commands and links, so you had to have underscores in your links. This time and again, this resurfaces in underscores capes showing up all around the code, or all around the region, what do you say? Yeah. So basically for each page there's a source file, there's a rendered file, there's a kind of... Actually, I'm not sure about that. Is there such a thing as a page name for each file? Yeah, there is. That's basically that's dera underscore dera b and that's the kind of base name from which the other thing is constructed. And there's of course, there are ways of linking to that which can be with or without underscores and there's the title in which the underscores are stripped. So actually, I would have liked to have this completed for a Ikiwiki explanation page on the various kinds of titles. Because this is like a, I think I'm under the impression that this is a recurrent theme of the wrong kind of entity showing up in plugins. I don't know. I know there's a couple of cases where the crazy escaped file names can make it hard to figure out what the right thing to type to get a wiki link is, for example, if you're looking at a page in your browser and you know what the URL is, but that doesn't mean that you can easily figure out what the actual page name is linked to it. My impression was that you can always get the page name you can link to by copy pasting the title line unless you set a major title. Yeah, exactly. Okay. But I don't know that if I've ever seen an example of underscores leaking out in the browser. Yeah. Give me a second. There has been both ways actually when you try to intentionally create an underscore in a Ikiwiki link, even if you explicitly set a title, you have to go the other way around and have to, I think this is a kind of traditional feature from what my impression was. And the others are the link map plug-in, just this. Okay, I can see link map having that kind of problem, yes. Yeah. Generally concerning the way links are put, how do you feel about incompatible changes with the link format? Because basically Ikiwiki, that's maybe not so well known feature, Ikiwiki does have a transition mechanism for that so you can call Ikiwiki to transition your pages from one version to the next. But I'm under the impression that not all users of Ikiwiki would have this applied if we went to go on making incompatible changes. So what's your opinion on that? Yeah, we haven't used the transition for many things that everybody has to do. There was a patch which I unfortunately haven't merged to change something about preprocessor directives and would have needed a transition, a mandatory transition. And yeah, I don't know that we could guarantee that everybody does it, but then again, I don't try to guarantee that everybody maintains their system so I'm kind of okay with this kind of transition, at least in theory, I think. As long as we don't have a lot of them. Do you think there's room for development so that actually I don't know about the current version number that there will be kind of a collective transition version again? Yeah, I mean the kind of transition you're talking about would mean a new major version number. And then we could kind of spool some transitions up and. Yeah, that would be the best way to do it if you have more than one pending, maybe the preprocessor directive thing and your thing or something. This thing is one of the things that I've been discussing the last few days with SMHB was the ratio of having tight links. For usually in the QBQ, much depends on the relationship between pages that's established by having a link from one page to another. And there are some plugins so far that create type links. So when you tag a page by saying tag this tag, this creates a link to the tag page. But also claims that this link is a tag relationship and you can later on query for all pages that are tagged thus, and thus differentiate between just linking somewhere and actively saying this is a page of tag. So category A. And we've been talking about generalizing this to, because it will solve the problem of, for example, implementing back trackers which have blocking relationships. This might lend itself to an extension to the link format because just, I mean, how often does the pipe character show up in a URL? There'd be room for extension. And the transition, if that's what you're thinking. Yeah, I think that would be an example of a four point 2015 version. Yeah, I don't know how it's related. It's about using page she sold in parent links. But maybe I can show you the use case where I had to actually do crazy stuff if you're interested. Do you have it online? Yeah, yeah. So just for the US layer, add them. Yeah. I'm very happy with the layout. It's always nice to see a new wiki wiki site that I've never seen before. So the thing is it's multilingual, a wiki wiki. And so what I was telling before that I had to actually translate the template here. And so we still have French on the footer, for example, even if you're in the English version. The main problem is about actually, if you go in the subpage, this is a parent link. And to get this with proper caps and nice layout, I need to actually have the page name that is like capital A association. That's one thing. And also if I have that in the US version, the English version, then it's not translated. And it's all about how this handling of page diesel and parent linking are related sometimes. So in theory, you prefer pieces or something? Yeah, I'm afraid you can't unconditionally uppercase, you'd rather have to use the page title. But this would not only solve the uppercasing. You can't use the page title for technical. I think that it doesn't know the page title at the point that it's doing parent link stuff. There are issues like this with dependencies of one thing or another. You can't always rely on having access to the page title. Okay, so we then depend on the full contents of the parent page, basically. Exactly, and then when you recompile, you have a, I mean, when you change one page, you have to recompile like everything else. Yeah, as far as your footer, by the way, there's something that I've wanted to do and never got around to it. But if somebody would like to do it, which is generalize the sidebar plugin into a generic piece of the page plugin. So you can have whatever piece is the page you like, and then you can have a file in this directory that's a sidebar for this subdirectory and below it. You can have a sidebar on the other side. You can have a header. You can have an overt notice, whatever. Basically, that would solve parts of the templating issue because the page would not any more consist of template. Well, the templates would become very simple because they consist mainly of sidebars. Yeah, I think you could probably end up with a template that's a bit simpler. I don't know if it would completely simplify it. Of course, this also plays into maybe getting a bootstrap, a Twitter bootstrap or some other modern theme for Ikiwiki itself. Yeah. I've seen one implementation of Bootstrap, but try to generalize it and terribly fade because it's just too much dependent. Basically, it changes the templates and then you're out of like, when you have any other plugins. But I'm perfectly happy to have a, it is possible now to have something in the page template that's conditional on the theme that you're using. So you can easily, well, not easily, but you can put it all in one template and then I can maintain it in theory because it's just one copy of things with branches for different plugins. So it's doable, I think. Somebody just has to sit down and make it work. And I put that piece in just to make it not possible it should work. Okay. It sounds like you're gonna, yeah? Could you go to your overview of the different page name things? Yeah. Especially the topic of index.mdwn versus pageb.mdwn is every time I do something with that, I have to look up the documentation again and then check which flag I'm supposed to be setting of the two flags there. And so I was just thinking earlier since we were talking about a transition in the format, does it make sense to maybe only keep one flag to keep URLs compatible per site but move the file around in the git when once the transition hits and just say we pick one of these versions and go with that. I don't really see a strong reason. I mean, the way I think about it is there's one way to do it on there's this index pages thing that maybe somebody uses, it was just added because somebody wanted it, I don't consider it a big deal. You know, I just, I print it out of my mental model and I don't have to worry about it. Yeah, but that's a good example because I don't know exactly which, the one way to do it you're talking about because I have no idea again at this point which things, which flag does what. The one way is the default way which is if you have page name.mdwn then you get a page name file. Otherwise, if you have a, if you want your index, the only index.mdwn you have is for a top level index because there's no way to have it otherwise. So it's a special case which is slightly ugly but other than that it's quite simple. So it means you have, if you have sub pages you always have a directory without an index HTML file and you get the directory listing if somebody lists. Well, if you have sub pages you make a sub directory and you put the pages in there and then you probably have a top level page. So you have subdir.mdwn which then links to whatever is in there or whatever. If you leave that out then yeah, you get a. Yeah, but if somebody strips off the last part of a URL until the slash. Then they might get a directory listing if you haven't added a page there but you can always turn on the auto whatever. Yeah, and then auto get auto-generated index.mdwns if you don't have them. Yeah, I still find the topic rather annoying to wrap my head around the studio. I think if I were gonna do it again I would just have the not have a translation layer between your input and your output file just have identical input and output and mix it mentally some sort of model. I think I've had discussions in all of the four combinations that can spring up there and there are proponents of all those varieties. So I think it's not too bad to have a single translation layer as long as all the plugins are aware that they just can't tell which is the source file which is the destination file but just go through the appropriate function of whichever it is in the particular cases and be done with that. Quick comment, your idea about the sidebar, it would actually solve my parenting problem because I could have a header file and in the various sub directory they would just replace that with the localized version. So. There is an open to do item about it with some ideas I can't even know it exists it's from about three years ago. So you'd be basically doing in the sub in the sub to page something like inline dot dot slash dot dot slash header or what was your idea exactly? It's essentially inlining but instead of having to manually put the inline directive in it just it says if you have say a div with ID equals. Oh yeah it would inherit just inherit down or something like that. Okay yeah that would actually be even easier. On the more crazy idea on end of the things I've been working on, there's been the topic of adding RDF semantics to icky wicky which is basically what you do when you have relationships between pages like this page blocks that page in terms of bug tracking or having a wicky trader through it. I start to think about having the whole index DB file as an RDF database because basically everything we state so far in there as far as I understand it is meta data about the pages which lands itself to being stored in RDF and could then be easily queried. The query results could be validated so we wouldn't have the issues of knowing what kind of scan data has changed. And I think that could solve some of the structured data problems or issues as well. But I'm afraid this would be bothering a minor rewrite. Something like you're talking about would be efficient or anything like that. You are right everything that's stored in the index DB. Yeah, everything in the index DB is per page and it's basically a hash from page to information. Is there anyone around who has used RDF in that context so far or with other icky wicky? I've covered the topics I've wanted to talk about. Yeah, that's exactly the thing. Sparkle is the query language through RDF and basically we could still have the regular simple page specs but we could form rather powerful queries toward the index database and have those results printed there and by caching the queries and the results we could observe if a change to the random pages necessary or not. This is kind of automatically done already for some page specs figures out that page spec causes it to depend on it's mail. But it only works for page specs and not for things like page title and other metadata and that would be just the same thing then. If we didn't have the generic sidebar solution we could do for example this on page title substitution with that. Yeah, so since we were thinking about optimizing the index database anyhow, do you from the top of your head know something that has a performance similar to SQLite or something so you don't have to rewrite the file continuously and that would store RDF triples? There are a bunch of databases that store RDF triples. Some of them just use SQLite as a back end. I mean a triple store is not something terribly complicated to set up in a database. I thought I'd tell a amusing story about SQLite. I was recently at a small Linux conference and ended up sitting down across from a guy who eventually transpired as the author of SQLite and we started talking about our respective version control, he's also the author of Fossil. So we talked about our respective version control back to Wikis, but he had a much better database story than I did. Is there anyone webmasters of www.divian.org around? You are part of the web team, divian web team. Would you want to switch from WML to Ikiwiki? What would be missing then? With respect to translation, there's a lot of things tailored around how it works with CVS, which is also part of the reason which stores us from switching to any other VCS, but I'm not objecting to any switch. There's a lot of auto-generated stuff in the website which I understand shouldn't be much of a problem with proper tailored Ikiwiki plugins, but it needs someone to write it. We also don't object to switch to Git, but we have to keep in mind that a lot of translators only want to check out the English language and their language and not the complete history and which gets pretty heavy for CVS history for well over 10 years and 30-something languages. So switching VCS from that point of view isn't that easy and also from the generation part. It needs someone to do the work. We don't object to it, but a lot of people have here switched to this and that and when we ask them to help us out to make the switch happen, people turn silent pretty quickly. I will add that while Ikiwiki is primarily a Git-based wiki, it actually now has excellent CVS support from what I'm told I've never actually tried to use it, but I believe that NetBSD or something like that is using Ikiwiki with CVS since they're back end is apparently managing okay. I'm personally absolutely not objecting to Git, but there are some constraints which need to be kept in mind if it works for people. I just get to my mind that there was one thing that I would have liked to present which is basically another way of extending Ikiwiki I figured out. The thing is when you do templates, there's sometimes the need to do something more powerful than just template substitution, but usually that comes with either very complex nestings of directives or nesting of inclusions or writing your own plugin which then again is under a completely, even if you write plugins for a particular Ikiwiki instance, they are not managed inside that wiki, but they are independent of it. What I came up with for basically in my level servers, Minecraft wiki was, where do I have it? Did I just, okay, maybe I forgot to link it there, is having plugins that are written as Ikiwiki, having templates that are written in Python instead of just plain text. The main thing of course is our security considerations, but given there is now PyPy Sandbox in Debian which can be restricted down to not being able to do anything apart from reading standard in and out. Always very leery of language sandboxes and I don't know if I wanna go there. Are you sure that it's restricted to this? Are you sure that it couldn't be used to reform side channel attacks against some other thing on the service just by looting the CPU and looking at the intervals between stuff or who knows? I mean, I'm very leery about putting a general purpose language into Ikiwiki. Let's see, I'm roughly as confident in PyPy Sandbox than I am confident in the JavaScript engine in my browser. And that's how confident it is? That's how, and that's, that amounts to, it's a reasonable assumption that it should, that if one managed to break out, there's a serious bug behind it as there can be a bug everywhere else that can be exploited. I mean, I just can't see this being a default thing. I am, yeah, and so you're still stuck with the current, not so great templates and people have talked about putting in new ones, but I'm never sure if it's actually better if it's just new. I didn't understand what- People have talked about switching to a different template system, but I'm never sure if it's actually a good switch or just something different. Well, one thing that was a bit annoying for me is that I had a nice wiki and I could actually hire somebody to translate it for me using the PO files and just set here is GTranslator, please do that. And then I tried to hire somebody to write some CSS for me or a template and it was completely impossible. So I for one would appreciate something that's a bit more in line with modern templating systems just because I don't have to do all the work myself. See, the only modern templating system that I know is Yassad's, what's it called? What? No, it's not Yada? Yes, thank you, Shakespeare, the Shakespearean templates which are type save, compile, crazy templates, which are great but are not appropriate for a key wiki. So I don't know modern templating systems and whenever I look at a templating system I always feel like it's not right. I've never seen one that I've been happy with. So. I mean, there is PSP. I think that if we had a built in language, maybe making it be JavaScript could be a much more web two point whatever we're at thing. More ideas or topics to bring up? One thing which when I talk to people about using icky wiki and try to make them use icky wiki, the really the hardest bit is it's really ugly by default. It's really ugly, let's not mince words. And it's really hard to make it pretty. I mean, you know how hard it was for me to make one particular site where you help me but else it's really ugly. So I know I totally failed to make it even a tiny little bit less ugly. So I think it would really help if anybody who has the skills to do this, I know nobody who does, would be able to attack it from this side because normal people, let's call them that, will not ever start using icky wiki as long as it's, yeah, as ugly as it is. That's, and it's a real pity because it's powerful, it's simple, it can do insanely complex things. But people won't start using it until such a point where you see a need to use it and it's always, at least in part about being pretty and appearing to be easy and appearing to be user friendly. And it doesn't appear to be easy and user friendly when you see a very basic web interface. Is that better? Is it better? Not really, I mean I stole one myself, yeah I stole one of those, the one by, yeah the blue view one, it's the one I stole. I mean having a bootstrap theme would help somewhat, but I think the larger issue that you're getting at is that icky wiki was developed for and by geeks who don't mind understanding this stuff and you can slap a pretty interface on it but that's really not gonna get the crowd who is on their Mac and has five seconds total attention span to devote to setting up their wiki and then moving on to the next shiny thing. You know there's a lot of, I'm not exaggerating. You know there's a lot of systems that do better and this is not an area that I personally feel that I need to work on and if somebody wants to make it really easy, find some way to make it easier to set up, great. I am interested in making it look prettier just because I like the default look but I understand why you don't want that to be your look and did I change, the default icky wiki site is still using the default look good. Yeah I, you know, I realize that that scares some people off that I think that that's okay. Are we just talking about better CSS or is there something deeper going on here? I mean you have to know how to use git, you have to know how to clone a git repository, you have to realize that you don't just when you clone a git repository, you're not cloning it from github.com with the repository that you created there and edited the page in line in your browser and so there's a few basic pieces of knowledge that you have to know. No I wasn't, I was talking about CSS mainly. I wasn't talking about all the technical background. At least in my, yeah, I'm really trying to get people to use git based tools and one common theme is people who are comfortable enough with the technical side. They are willing and able to do all the technical stuff but they want and need something which is pretty simply because when they show other people they don't want to be told hey your website is ugly. So it's really mainly about the end user look about CSS about whatever to make it. I think that's completely solvable. I mean would you feel if it had a bootstrap look and it was fairly well integrated you could say for example add tabs to the top of the bootstrap thing like you normally see on bootstrap sites and that kind of thing would that be sufficient or do you feel that it would need more prettiness than that? I think it wouldn't need that much prettiness but it would need a common web accepted level of prettiness. I mean when you look at random websites most of them aren't very special at least to me but they have a somewhat higher level of prettiness. Can you find the bootstrap example there? It should be in the theme market I think. Also I can, I mean I can totally, I have like at least probably on my mind find five icky wicky websites that I find really pretty. Most of them that I know had to hack on the templates also because they were French but I can still like show you what you want. Yeah sure and put them up on the template please. One thing that, one thing I've thought is if we push at least the admins of the site to jump through these hoops to stand on a better and cooler technological background I thought it's a bit of a shame that we don't use this information that we have so well. So icky wicky will tell me when the page was last changing it but what I see is that we have not enough information to show a nice history like media wicky does we could even show a nice branching and merging graph like github does out of the box. So how do you feel about icky wicky digging through the history to extract that kind of thing? Well in a way I like keeping it simple and just saying here's how you can integrate it with GitWeb or with your browser of choice so that I don't have to worry about maintaining all that stuff. On the other hand I think it'd be great if there were some kind of a plug-in or something that could go back and render historical versions of pages on the fly and be able to browse back through the history and that kind of thing. So that's kind of a dichotomy. I don't know which side of it I come down on. I think that if somebody took the work to make a plug-in that did something cool with a Git history I would probably say okay fine I'll put it in as long as it didn't have a lot of crazy dependencies or something. I think you're very right about not taking advantage of all this and my original idea with a KiWiki or with what came before a KiWiki was to have probably a dynamic Wiki that allowed you to actually fork and traverse different forks and go back and forth and all that kind of thing. You know on the fly and see the site as it was at that point in history and so on and take full advantage of version control. So but moving to a static site kind of took a little bit of that away. So, okay. Are you still trying to show other themes? So all of these are like KiWikis based. You have JavaScript, do you activate it? Could you just activate JavaScript on this one? Yeah, just this one, this is all. To show you, this is one trick that I came with so it's a radio show and you still don't have JavaScript anyway, do you? Maybe it's broken, but so basically you have JavaScript that finds the MP3 links and replace them with an online audio tag. So actually you get to get the radio show. Can you back up to the others? That's one. That's J-Y-I-S-P, it's also, this is a quickie. This is a quickie. I want to show you already. Griggy, on a very, more or less same people than I think, but he's still like a quickie. One thing that is nice was submitted was the issue going on the front page. Probably there is a, yeah, you still have JavaScript deactivated. So there's a calendar here that is actually working with calling JavaScript to display a calendar in a way that is actually a feature, no. Yeah, because otherwise it was too slow to rebuild every single page, every time the calendar changed. So that was submitted I think, tales. The biggest EQE website that I've ever been as far as I understood, because they were like, several thousand of pages of comments so I mean, I should give you a quick tell. Before we disabled our web forum, like a month ago we had about 3,000 threads and something like 10,000 comments and rebuilding the whole website to update the site bar that shows the latest release version was a bit slow. We had talked earlier about the multiple sidebar things is kind of one of the blockers to it is that I know that people are gonna get into this kind of situation with other things. If it has the ability to have a header and a footer and all that they're going to realize that oh if I change this, it takes us to rebuild and it takes forever and so we need some kind of solution to that. Yeah, but it already does with the sidebar so. Well yeah. And actually people are putting stuff in the sidebar which is general. That's a big problem. I have to support, you know, I often have to help somebody who tried to put a calendar in there or something that didn't fully realize the implications of that and there really ought to be a better way but so far I haven't found it. I think the, are you running with Poe on all of your, okay. So it's only a few pages that are using Poe and then the rest was just a scalability of the index file probably. Yeah, I think we're a little out of time for people who want to join other talks. Are they, let's say final questions at least for the part that's being recorded or that's the general official Debcon 13, Ekiwiki, POF. So that's, thank you Joey for answering many questions. Well thank you for organizing this and putting it on. Thanks for joining here.