[00:21:08] --- Simon Wilkinson has become available [00:25:21] --- abo has become available [04:28:55] --- SecureEndpoints has left [04:29:01] --- SecureEndpoints has become available [04:58:57] --- edgester has become available [04:59:52] --- edgester has left [05:00:31] --- edgester has become available [05:00:38] gm edgester [05:00:42] gm [05:00:48] sorry, pidgin died on me [05:01:39] its ok. happens. some of us even go on vacation. two weekends in a row without a laptop. I'm in heaven. [05:01:58] I'm jealous [05:02:23] I'm only allowed my laptop because Hazel is at work. First wedding anniversary today! [05:02:43] as an fyi, I'm around today and tomorrow but will be offline through Sunday. I will be in the mountains of Colorado with my wife and dog [05:02:44] congratulations! [05:03:14] Let me pick your brains, whilst you're still around then, SecureEndpoints. [05:03:22] has a year gone by that quickly? my 2nd anniversary must be coming up soon [05:03:39] let me get to edgester first since he is before you in the queue [05:03:46] Sure. np. [05:05:00] over the weekend there was a discussion of project management, web site updates, elder's meetings, and many other important subjects. I wish I was around for it and I think that the way to make sure that someone is around for those types of discussions to take place is to hold public offlice hourse [05:05:02] hours [05:05:35] --- abo has left [05:05:40] --- abo has become available [05:05:40] sounds good [05:05:45] I don't think that the holders of that discussion were expecting others to chime in, though. [05:05:54] or just have some type of weekly/monthly meeting [05:06:08] let me try to go through the topics one by one. let me know if I missed something. [05:08:03] k [05:08:51] web site redesign. jake has been working on a redesign in his spare time. he has found that between classes and his campus job that he had much less time than he expected. Also, the complexity of the relationships between the various web site audiences produced an extremely complicated graph of web pages/content. We are working to try to prioritize the graph relationships. [05:09:40] The webmaster@openafs.org mail goes to jhutz. Most of the updates are committed by Derrick or myself. [05:11:07] k [05:11:21] Other than portions of the release pages, there is very little that generates automated content. For example, updating the man pages on the web site is done by slurping in the html that is produced by generating the Windows binaries. [05:11:36] I kinda figured that [05:12:08] If the QuickStart guide is automatically generated by the build system, then I will be happy to slurp that into the web site repository as well. [05:12:12] The automation of the release pages is time consuming, too. Which is why there are usually many more Linux RPMs in the repository than are shown on the sevsite. [05:12:20] SecureEndpoints: It's not, sadly. [05:12:49] er? [05:13:03] The docbook dependencies are pretty expensive, so the XML stuff doesn't get built. [05:13:10] s/expensive/extensive/ [05:13:11] Derrick and I have tried periodically to entice community members to help write tools to assist with the automation. There have been few volunteers. [05:13:29] I have been among those failed volunteers, sadly [05:13:37] --- abo has left [05:13:40] add a "docbook" make target [05:13:42] I can give you tools to build the docbook automatically. Do you have a host you can run them on? [05:13:57] grand doesn't have the necessary software installed. [05:14:03] we do not build on grand [05:14:24] docbook is installed on my Windows dev box. [05:14:31] --- abo has become available [05:14:53] Cool. We could also just build them on lochranza, and rsync them in with the Linux RPMs. [05:15:41] I want them in the build system so that the output can be installed locally as part of the Windows installers [05:15:53] They're in the build system, actually. [05:16:08] doc/xml/QuickStartUnix/Makefile [05:16:33] not on 1-5 branch [05:16:43] I suspect not on 1.4 either [05:16:44] I suspect that the XML has never been pulled up. [05:16:51] Definitely not in 1.4 [05:17:04] --- stevenjenkins has left [05:17:21] Is there any reason not to pull these up? [05:17:56] not that I am aware of [05:18:27] Shall I open an RT ticket? [05:18:41] yes please [05:19:24] I also need a vounteer to work on a Windows quick start guide [05:20:07] --- stevenjenkins has become available [05:20:35] [05:20:55] I have sources for an update but it is out of date [05:21:07] they were done back in 2004 [05:21:25] As changes against the Unix Quick Start Guide, or from scratch? [05:21:39] they should probably be pulled up [05:21:43] Windows already had its own. [05:21:57] Ah. Okay. [05:22:15] The quick start guide for Windows was re-written from scratch. The output is actually in the Wiki [05:23:07] http://www.dementia.org/twiki/bin/view/AFSLore/WindowsEndUserQuickStartGuide [05:23:30] there is also a configuration refernece http://www.dementia.org/twiki/bin/view/AFSLore/WindowsConfigurationReferenceGuide [05:25:49] --- SecureEndpoints has left: Replaced by new connection [05:26:06] --- SecureEndpoints has become available [05:26:31] next topic: project management and the projects.html page [05:27:17] As we mention every year at the workshop during the "Futures" talk, the gatekeepers do not have any resources of our own to manage. [05:27:48] Therefore, it is extremely difficult to make commitments about when things will be accomplished. [05:28:01] I don't think anyone is looking for commitments, tho. [05:28:34] I think the point that was being made was that there's no public information available about who is working on what. [05:28:36] To a large extent the roadmap is a joke because we cannot make commitments [05:28:53] going backwards for a moment, even the release pages are not automated. we have a script; it is run by hand [05:30:09] well, we could tell people to talk to hartmut and felix about osd, marcus and matt about rxk5, tom and mike about dafs, but beyond that, i don't know that we know who's working on what until a box shows up on the porch [05:30:49] a box on the porch? is that a code drop? [05:30:51] Yeh. But if people knew that that information was being collected, and disseminated, it _might_ encourage them to share more with you. [05:31:10] yeah [05:31:41] Derrick and I were flogged a few years back at HEPiX by senior management at various organizations. Part of the reason they were putting resources behind Lustre was that Lustre had a plan with commitment dates and they (a commercial company) were good at accomplishing the goals they committed themselves to. [05:31:47] well, it'd have to encourage customers to disclose, in some cases [05:32:11] yeah, that was fun [05:32:13] --- dev-zero@jabber.org has become available [05:32:19] --- dev-zero@jabber.org has left: offline [05:32:45] ? [05:32:46] There are lots of open source projects which don't preannounce new features. Heck, there are lots of commercial projects that don't do so, either. [05:32:55] getting flogged. [05:33:05] we're not just any open source project [05:33:13] no, I imagine that wasn't fun [05:33:26] I think the problem is that there's a perception of no progress being made, because progress tends to never be visible. [05:33:36] agreed [05:33:47] I'm not asking for deadlines. [05:34:08] I was just asking for more information about what progress is being made [05:34:41] --- abo has left [05:35:04] You can define progress by the source code releases. The problem we run into is that we have wish list items on the roadmap which have received no attention for years. [05:35:09] For example, central IT service here were speaking to NAS vendors. They were asking about AFS. Everyone they spoke to who knew about it said it was dead, when challlenged on that several pointed to the lack of changes on the web site as being their justification for that. [05:35:16] A monthy email about what's going on would be great. Kind of like this http://lists.maemo.org/pipermail/maemo-developers/2009-May/054739.html [05:35:22] --- abo has become available [05:35:26] although not focused on bugs, so much [05:35:30] who will write it? [05:35:45] I will [05:35:47] I have asked repeatedly over the years. [05:35:50] excellent. [05:35:55] Here is what I want [05:35:58] You can't define progress by source code releases. In general, nobody reads the release notes, and absolutely nobody from the Unix side reads them for the 1.5 series [05:36:14] you can tell me what you will deliver [05:36:41] I'd humbly suggest that if we are doing a monthly email, it should contain what the community wants to hear, rather than what we want to tell them ... [05:36:46] Since our community is so fragmented, what I would like to see is a summary newsletter posted to the web site and an RSS feed. [05:37:11] Simon. please wait [05:37:25] I want to make a list of current projects that you can talk about, who is working on it, and a short sentence or two on what's changed [05:37:32] the reason there is no new content on the web site is because no one writes it [05:38:10] if that is all you want to do, send updates to the projects.html page [05:38:20] I chimed in for updating web content at one point, but never got follow-though. I also bugged jhuts a few times to help with RT, but that failed [05:38:50] send a patch for the web page just like you do for the docs [05:39:07] I think it would be much better as a regular email newsletter. [05:39:21] If the webpage gets updated as a by product, then so much the better. [05:39:50] I think I'd like to try the newsletter and have the wbe site be version 2.0 if I keep up the newsletter [05:40:03] Post it to the web site. Then the newsletter becomes a summary of what is happening in the community [05:40:14] the newsletter can be linked to the web site [05:40:21] --- abo has left [05:40:26] i'd be happy for you to have commit access to do it, really [05:40:52] --- abo has become available [05:40:54] ok, so give me commit access and give me instructions on how to update the web site [05:40:58] and that summary comes from a monthly review of the important topics that were discussed in the various forums with URLs to the e-mail threads in the archives, chat logs, etc. [05:41:52] sounds good, I'll see what I can pull off. [05:41:52] the web site is just a bunch of static pages that are maintained in a cvs repository. [05:43:01] edgester: It would be good to do one before the workshop, as then there's somewhere to get feedback about whether the information in it is useful to people or not. [05:43:20] website update instructions: emacs, cvs commit, update_htdocs openafs [05:43:53] I'll get one out before the workshop [05:43:58] as to giving you powers, well, not me. but as it happens, jhutz promised he'd play catchup today, since the race he covered was yesterday [05:46:40] as for Elders meetings. We meet. We have minutes and they (and the gatekeeper reports to the Elders) with redactions for confidential info really need to be posted. [05:50:18] the real problem is getting them in a postable format [05:50:32] --- tkeiser@sinenomine.net/owl has left [05:50:44] well, the *first* problem is getting a copy from laura [05:50:59] the minutes are all in the mail [05:51:19] when it gets sent [05:51:52] I think of everything Jason and I discussed over the weekend, this is the most significant from a governance perspective. [05:52:09] no disagreement [05:53:19] I will try to go through the web site and refresh the content before I leave for Colorado. [05:57:23] thanks [05:57:40] so, do I need to bug jhuts for cvs access? [05:57:45] ugh, jhutz [06:00:14] A couple of things I'd like to build, and don't currently have anywhere obvious to put are [06:00:26] a) A list of academic papers written about, or citing, OpenAFS [06:00:35] wiki? [06:00:44] b) A list of all of the half finished protocol specifications that have been written over the years. [06:01:02] The Wiki would be good, but I don't think anyone actually finds stuff in the AFSLore wiki. [06:01:09] I do. [06:01:14] It could go into the AFSLore Wiki whilst its being built, certainly. [06:01:44] and the AFSLore Wiki is indexed by google and connected to the search button on the openafs website [06:02:38] the wiki is a good place to edit it; we can direct-link wiki pages off the website elsewhere [06:03:09] Simon. you wanted to discuss something else this morning. [06:03:18] ok, to summarize, I will start writing some type of monthly newsletter and I'll need CVS access to put it tothe web site. How do I proceed about getting access? [06:03:20] see e.g. how the wiki is embedded into prr.dementia.org/documents/ [06:03:43] it meant in that case that i could stop managing a static html page of links to documents, in fact [06:03:58] you can start by writing the document and submitting it to RT. posting is not hard. Writing is [06:04:01] jason, read your private email (not work) when you can [06:05:00] cool,. got it, thanks! [06:05:08] I'll work on writing something. [06:05:20] edgester: I think, that to get the most immediate gain from a newsletter, mailing it out is the way to go. So don't let a lack of web access stall you! [06:06:04] Simon Wilkinson: I'll do that. I'll run it my the three of you first, though. [06:07:11] Thanks for the chat, I'll talk to everyone later. [06:07:18] k [06:07:21] have a good day/afternoon! [06:07:24] SecureEndpoints: Yes. [06:07:36] My topic was returning results from the metadata search engine. [06:07:37] --- abo has left [06:07:38] --- abo has become available [06:08:01] (Rini asked this by private mail over the weekend) [06:08:18] I think my preference is to return both a FID, and a relative path from the volume root for one instance of that FID. [06:08:23] --- edgester has left [06:09:00] it would be nice if she'd come back and ask it here [06:09:48] Yeh. I'm trying to persuade her to do so, but she's busy with end of course stuff at the moment. [06:09:53] that seems reasonable in terms of what people will want. it does add the complication of finding or storing that path (where if stored it can become stale) [06:10:00] the question I asked of RedBear/Rrrrred (aka David) as part of the public comments was "how will the query results be used?" [06:10:37] I know how I'd like to use them... [06:11:16] One of the tools I suggested as a deliverable is a command line tool that performs a query and outputs usable paths based upon the context of the client. [06:12:13] For example, on Windows a query result could be reported as \\afs\{%,#]\\ [06:12:29] On Unix, there is a different notation that I never remember. [06:12:31] Yes. [06:12:42] But, I think that violates the principle of least surprise. [06:12:58] In what sense? [06:13:01] The user is going to expect to get back the path that they 'know' the file as. [06:13:17] they can't. the indexing server won't know that [06:13:28] No, but you can make a bash at working it out. [06:14:25] I do suspect, though, that 'making a bash' might be beyond the deliverables for SoC, as it's going to require cache manager changes. [06:15:10] In terms of your volume, relative path syntax, my suspicion is that it's going to be easier for the indexing server to determine the relative path of the file than it is going to be for the client to do so. [06:15:26] even if the CM maintained a graph of volume relationships so that constructing full paths were possible, it could only be used by a CM that has prevously accessed the object via such a path. [06:15:45] Indeed. [06:15:57] So, you'd only ever be able to 'make a bash' at it. [06:15:59] and the index needs to be usable by all CMs [06:16:05] actually, the user only expects a path if you show them a path, and not a file [06:16:51] The index within the volume can maintain FID and relative path from root of volume. [06:17:11] That can be determined by the indexer without help by the client. [06:17:22] Indeed. That was my point. [06:17:39] In the case where there is more than one valid relative path, we'll just choose one. [06:17:40] it is also the only canonical info. What is displayed to the user must be platform specific. [06:18:05] how can there be more than one? [06:18:09] hardlinks [06:18:24] we do not support hardlinks across directories [06:18:34] No, but we do support them within a directory. [06:19:08] --- abo has left [06:19:08] That's what's currently breaking disconnected's directory replay handling :( [06:19:25] it broke the windows native client as well [06:19:34] --- abo has become available [06:19:53] requires a pretty thorough redesign of the file control block - directory entry architecture [06:20:27] It's going to require a redesign of disconnected's directory stuff, too. Which is why it isn't fixed yet. [06:20:54] but hardlinked names in a directory are much easier to deal with than in multiple directories and I do not think we need to consider symlinks [06:21:26] of course, CMs that support direct to FID access will not require the path info. [06:21:30] I'd agree that symlinks don't count. You should never get a symlink as a search result. [06:22:08] unless you are searching for names [06:22:12] Yes, which is also Derrick's point about GUI based searches. But, I think that a user will expect a path. If they get back this wierd syntax that they've never seen before, they're going to be confused. [06:22:40] Our current design doesn't permit searching for names, unless those names get explicitly pushed into metadata files. [06:22:54] true [06:25:37] looks like no one has edited the wiki in a couple weeks [06:25:47] Are edits broken? [06:26:08] well, it looks like i failed to install rcs! [06:26:29] That wouldn't help things ... [06:27:08] The \\afs\#\\ syntax is gaining traction on Windows. Especially for home and project directores [06:28:39] I suspect using it on Linux will make the kernel rather sad. Not so keen on things which are mounted in multiple locations... [06:28:45] I think we have consensus that the RPC response should be FID and volume/relative-path [06:29:07] Cool. I will relay that back, along with continuing to suggest asking questions here. [06:30:43] the gsoc students seem to be much happier using IRC. [06:31:17] here/IRC, doesn't really matter. "In public" is what I'm trying to encourage. [06:31:19] i'd prefer here [06:31:24] irc if they must [06:31:54] how would you feel about weekly mentor reports? [06:32:23] As in student=>mentor, or mentor=>community? [06:32:29] yes [06:32:50] 4 weekly reports to the community might be a little noisy? [06:33:10] I think a monthly report to the community, as part of Jason's enterprise could be a good thing. [06:33:14] fine. student -> mentor -> gatekeeper -> community [06:33:19] I think weekly reports to mentors are good, too. [06:33:28] But I don't think they should be formal. [06:33:56] Just that a mentor should be engaging with their student _at least_ weekly, and have a good idea of where the student is, progress wise, each week. [06:33:56] let's not get too bogged down in reports [06:34:15] the time period for gsoc is very short. by the time a monthly report got integrated into a newletter the important feedback opportunities would be missed [06:34:40] I don't think we're looking, in this case, for it to be a two way channel. [06:34:41] as administrator, I want an idea of what the progress is [06:35:04] if the discussions are held publicly, there is no need for a report. [06:35:20] if I never see discussions in the public forums, I need a report [06:35:37] Sure. I think the danger of calling it a 'report' is that everyone gets this impression of a formal, written document. Which I don't think it needs to be at all. [06:35:38] --- stevenjenkins has left [06:35:59] But, if a mentor goes a week without any idea of what their student has done, then there are problems with that mentor, that student, or both. [06:36:13] exactly, and I need to know both [06:36:22] if the mentor is failing, I need to step in [06:37:00] --- abo has left [06:37:26] Sure. [06:37:37] --- abo has become available [06:38:57] --- stevenjenkins has become available [06:39:41] From last year, what worked was that I pretty much knew each week what Dragos's progress was, and what his plans for the week were. He was also very proactive about letting me know when he encountered problems. I think that helped hugely with avoiding things getting bogged down, and with any rising sense of "how on earth do I get this all done in time", which I suspect hits everyone at some point in SoC. [06:40:10] Dragos and Jake both were in IRC continuously [06:40:26] Yes. [06:40:41] and it meant that everyone was able to chime in with help as needed [06:41:10] I think the problem is that IRC can be perceived as combative (not necessarily #openafs, but irc in general) [06:41:33] I have never had that perception of irc [06:42:43] that said... while I'm doing my best to encourage hanging out in irc/etc during this "getting to know each other" period... it might be helpful if openafs sent out a "welcome... getting to know us, now... what we expect of you, etc" intro email to the gsoc participants [06:43:27] would you be willing to start making one? [06:43:56] i may vanish again briefly. my router is ~unhappy. i am fixing [06:43:58] it shouldn't come from me as I don't represent afs [06:44:10] you can't write something you won't send the final version of? [06:44:36] it should come from one of you gatekeeper/elder-ish folk [06:44:45] They can send it. [06:44:50] who did this last year [06:44:53] Doesn't mean we can't put words into their mouths. [06:45:08] "Free beer will be supplied to all mentors..." [06:45:12] someone did it last year? [06:45:20] i often supply myself free beer [06:45:20] this = gsoc [06:45:37] Free beer was supplied to mentors, now you come to mention it ... [06:45:43] --- stevenjenkins has left [06:46:37] --- abo has left [06:46:41] I already sent such an e-mail [06:47:10] awesome [06:47:24] as a response to the e-mail, the students sent their introductions to openafs-devel [06:47:29] --- abo has become available [06:48:14] still, it is the mentors that need to bring the students into the public light. The best way is to refuse to answer questions in private mail [06:48:58] From my experience last year, I have to disagree with that. [06:49:07] --- stevenjenkins has become available [06:49:19] The best way is to convince the students that they will get a fair reception asking questions that they believe to be stupid in public. [06:50:50] there are kind ways to do so. "I think that question deserves to be asked in public so that the gatekeepers and other mentors have an opportunity to respond and/or review the conclusions of the discussion." [06:51:50] "I believe that other openafs developers would benefit from hearing the answer to that question, could you re-ask it in the Jabber conference room?" [06:52:36] I don't know about your experience with the mail lists but I have to push back a large number of responses to my responses back into the list queue [06:52:45] Agreed. The problem is the same as when joining any community - the tendency, especially if you are shy or nervous is to hang out at the edge of the room, perhaps interacting quietly with a small number of people. If someone forces you to go stand in the middle, sometimes you'll do it, other times you will just leave. [06:54:22] Beyond asking students to introduce themselves on openafs-devel, what else have they been asked to do during the Community Bonding Period? [06:55:01] Speak with their mentors. Improve the definition of their projects so that on day one they can be productive writing code. [07:00:19] of course, most college students are now right smack in the middle of finals period [07:00:34] understood [07:00:38] Oh yes. Which is what happened last year. [07:00:42] (for U.S. students) [07:00:54] Ultimately, the first ~2 weeks of SoC will be a wash out in terms of actual real code being produced. [07:01:02] Cornell's finals are for the next two weeks, as an example [07:09:47] well, that was painful [07:12:47] in the doc/xml/AdminGuide/ directory there is .xml, .html and .pdf. I'm going to assume that the .pdf and .html output should not be present in the repository since it is generated content. Or am I wrong? [07:13:03] secureendpoints - correct [07:13:32] well, unless we want the generated content there. the toolchain to build that content may be considered onerous.. [07:14:13] it may be onerous for users, it should not be onerous for packagers [07:14:51] Building it should probably be part of regen.sh [07:16:00] --- abo has left [07:16:14] --- abo has become available [07:56:56] --- tkeiser@sinenomine.net/owl has become available [08:01:29] --- abo has left [08:02:45] --- abo has become available [08:14:53] was there a conscious decision to use DSSSL instead of XSL for docbook transformation? [08:15:17] I think its what the docbook tool set came with at the time. [08:15:26] I know that there are issues with the DSSSL translation. [08:16:32] I think docbook-xsl is a separate package [08:19:40] I suspect that when the initial docbook translation was done, XSL wasn't very mature. [08:20:35] the docbook that was produced for Windows used the XSL because the XSL translations permit the auto-generation of Windows html help [08:23:13] which docbook dtd was used? [08:23:48] I have no idea. [08:24:28] From the code : Did the GetTokens pioctl change between 1.4.x and 1.5.x? 1.5.x user space 'vos' seems to not play well with a 1.4.x cache manager. [09:14:03] in the QuickStartUnix directory. Should there be a auqbg009.xml file? It is referenced as an entity but does not exist in the repository [09:15:40] That's the index. [09:15:48] It's autogenerated by the Makefile. [09:17:09] not so much on Windows [09:17:18] No collateindex.pl? [09:17:21] --- SecureEndpoints has left [09:17:31] --- SecureEndpoints has become available [09:18:16] not part of the perl distribution [09:18:35] It's part of docbook, I think. [09:18:38] Lemme see. [09:18:55] the xslt tools generate the index as part of parsing the docbook tags [09:19:05] Yeh. It's part of docbook-style-dsssl [09:19:31] not using dssl [09:19:34] dsssl [09:20:20] Ah. That might be a problem. I think that all of the current work has been targetted at DSSSL. [09:20:51] Of course, if XSL produces better results, I doubt anyone is wedded to DSSSL. [09:21:07] at this point I suspect XSL produces better results. [09:23:12] --- abo has left [09:23:37] --- abo has become available [09:40:54] Hmmm. I have an AFS build here where xdr_int is being satisified by glibc. I suspect this isn't going to end well ... [09:54:50] please take a look at /afs/athena.mit.edu/usr/j/a/jaltman/Public/OpenAFS/QuickStartUnix.html [09:56:51] that is a very large HTML file [09:58:04] of course, that output doesn't fix any of the docbook element inconsistencies that are in the XSL sources [09:59:19] the various anchor links appear to all work [09:59:36] the Index is auto-generated by xsltproc [09:59:36] Sadly secure-endpoints.com doesn't want to serve that page to me ... [10:00:39] http://www.secure-endpoints.com/AFS/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/QuickStartUnix.html works for me [10:00:44] it works for me as well [10:00:57] http://tinyurl.com/den44l [10:01:54] Ah /usr/ against /user/ [10:05:01] refreshed. all of the links will now work [10:07:41] The DSSSL translation I did a couple of years ago is at http://homepages.inf.ed.ac.uk/sxw/OpenAFSQuickStart/ [10:08:09] and the HtmlHelp version is at /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/QuickStartUnix.chm [10:08:44] I don't think the XSL one is any less readable than the DSSSL one. [10:08:55] I think both a typographically worse than the IBM documentation. [10:09:14] we haven't done anything yet with style sheet customization [10:09:25] It might be nice if the XSL could be paginated in some way (split into chapters, perhaps) for easier web use. [10:09:40] the html help engine does that [10:09:45] SecureEndpoints: Yes. And you've at least got more of a fighting chance with that with XSL. [10:10:21] I think the XSL one has fewer formatting artifacts than the DSSSL one, too. [10:11:45] take a look at http://www.secure-endpoints.com/openafs/QuickStartUnix/ [10:12:59] Only niggle would be that having 'Next' and 'Last' links are helpful for when you're reading through, rather than linking around. [10:13:48] That was the htmlhelp output which is the input to the Windows Help Compiler [10:14:30] I need to figure out how to use the website.xsl autolayout.xml to produce an equivalent web site [10:21:17] the website html generation is different than the single file html generation that I just produced. For the website version we design a website design and construct a layout. The output can then be multiple directory levels along with frames, etc. [10:22:28] I'd greatly prefer something without frames. [10:33:39] its all defined by the layout. I need to finish reading [10:55:01] --- Russ has become available [11:34:16] --- dev-zero@jabber.org has become available [11:34:17] --- dev-zero@jabber.org has left: offline [11:36:54] looks like we can't use the website DTD directly with the docbook xml files. website is derived from simplified docbook but it is not a direct subset. [11:37:22] website might be a good tool to use to implement the openafs website [11:39:04] instead it looks like we want to use html/chunk.xsl [11:40:02] take a look at the new http://www.secure-endpoints.com/openafs/QuickStartUnix/ [11:49:07] That looks pretty good to me. [11:50:47] I think it is good enough for the web site [12:26:06] and now with graphics for the navigation controls [12:27:22] PAM session example appears to show up twice at the bottom of the page [12:27:58] although maybe that is by design [12:31:48] it is by design. The examples are different. The names should be altered to distinguish them. [12:34:44] I altered the titles [13:54:08] If I can figure out how (aka what the correct method is) to update the www.openafs.org/doc/ path I will do so. [14:20:13] SecureEndpoints: That looks really good. Thanks! [14:25:01] --- Simon Wilkinson has left [17:19:19] --- Russ has left: Disconnected [17:38:34] --- Russ has become available [20:12:34] --- Rrrrred has left [21:42:25] --- Russ has left: Disconnected [21:46:21] --- abo has left [22:05:36] --- Russ has become available [22:41:37] --- reuteras has become available