[02:13] * yod chatting with Yves on... hardware issues in the meantime [02:13] seems like the css-validator is dying on us, BTW and FYI [02:13] well, the server, that is [02:14] yod: well it's 500MHz box, now serving > 6Mhits.day [02:14] how many of those hits are non-static? [02:14] what's the average load, again? [02:15] now it's down to 8, which is ok [02:15] but when there are validation burst, the machine is just dying [02:15] it's fairly responsive at load < 15 [02:16] we have donations on our agenda, BTW... [02:16] niq: the % is fairly low on the long term, but the issues comes from "bursts" the distribution of hits is definitely not nice [02:17] and the css val isn't apache, so mod_load_average won't apply [02:18] well apache won't be able to handle 800 concurrent connection on that hardware anyway [02:18] Yves will know better than me, but I think the server is rather fine-tuned for its use (icons + validator servlets), no? [02:18] especially with the way apache handles persistent connection, with a fixed timeout after the reply was sent [02:19] so apache 2.1 with the Event MPM and mod_load_average [02:19] yod: well it's designed not to care that much about the content served, but the parameters has been tuned to this specific box :) [02:19] I see [02:19] what OS and JVM does it run? [02:20] sol28, and jdk1.4.2_06 [02:20] I'm waiting for new hardware, and it will be linux, kernel 2.6 (using nptl) [02:21] the current box is at least 5 years old [02:21] That plays well with Java? [02:21] yes [02:21] lists.w3.org has that setup [02:22] even if the machine is regulary swamped with spam processing, but that's another issue :) [02:22] in case of Linux 2.6, BEA's JRockit might be worth trying too [02:23] yes, I heard about this and wants to do some tests with it, but didn't find time yet [02:24] BTW, what'll the new hardware be? x86? Custom, off-the-shelf? [02:24] I've had some good experiences with running 24/7 server stuff with it [02:24] bi xeon 2.8G I think [02:24] but it's a production beast, not a development one [02:24] with 2G of ram (current machine is 1G "only") [02:27] Yves suggested that we could use the W3C donations mechanism (generally designed for corporate donations, but nothing stops from receiving personal ones I assume) to get at least some hardware budget [02:28] i.e donation link from the validators' homepages [02:34] * xover has reservations, but no better ideas... [02:34] erm, surely that's a decision for w3c officialdom rather than hackers? (i.e. you, not us:-) [02:36] niq: right, was just wondering about the hackers' views on the idea, which could well range from "don't care" to "this sounds like a very stupid idea and will alienate soandso" [02:40] bjoern: context was using w3c donation mechanism to refresh our hardware for validators (3 machines at the moment : validator, jigsaw, qa-dev) [02:40] * JibberJim doesn't think it would alienate anyone that's likely to matter. [02:41] you mean like W3C does not even want to spend money on qa-dev hardware? [02:43] it's tough to get budget for anything at W3C these days [02:44] it's more about finding budget to be more independent than getting any money at all, though [02:45] or remain independent, for that matter [02:46] more community driven than w3c-member driven [02:52] One thing I had put on the agenda is "fragment upload" support [02:52] there is some demand to bring it back [02:52] We never removed it! [02:53] well, it's not linked from anywhere and there's a large "here be dragons" sign on it [02:53] other than that, yes, it *is* still there [02:53] so this is a feature request... [02:54] yes [02:54] and we all agree to have it, so, what's the issue? [02:54] and here indeed be dragons of hackery [02:54] all agree? do we? [02:55] issue is, the sign says it's broken. I am wondering if someone knows how broken it is [02:55] xover? [02:56] Fragment upload is not fragment upload, it is validate-from-textarea [02:56] Fragment upload is pretty fragged. [02:57] All issues I know about have to do with character encoding issues... [02:57] bjoern: just so it's clear, we're talking markup valdiator here [02:57] yes!? [02:57] other approach: use custom DTDs for HTML-fragment and XHTML-fragment [02:57] It was implemented before all the various knobs related to DOCTYPE, Content-Type, Charset... [02:58] It doesn't use any of them, and is quite likely to show up bad behaviour as a result of them. [02:59] If you mean that http://qa-dev.w3.org/wmvs/HEAD/fragment-upload.html should validate e.g. even if there is only a

...

then I do not see demand for that. [02:59] I am talking about full documents, yes [03:00] but according to xover even that does not work as it should [03:01] niq, you talking about full documents, too? [03:01] aaargh, that page crashed firefox! [03:01] It'll be broken for more documents than url-based runs, yes. Mostly due to the metadata related issues though, I expect. [03:03] I use it about once a month and it works for me... [03:04] Then it may be in better shape than I fear. [03:04] alright... then I guess we can update the warning, link from $home and wait for bug reports... [03:06] agenda+ feedback form [03:06] re: http://lists.w3.org/Archives/Public/public-qa-dev/2005Jan/0003.html any suggestion on the proposed choices? [03:07] options being: 1- form sends mail to w-v@, 2- form creates mail template and user sends it, 3- something more complicated [03:08] * xover not terribly fond of either option, but ditto's yod's asessment given those choices. [03:09] any other idea I did not think of yet? [03:09] 4- Status Quo, 5- take a step back to where we used to be, ... [03:10] right. although I'd rather not go there [03:11] I think I will ping a few people I know developed things similar to 3-, and will fall back on 1- if that does not seem reasonable [03:12] Try #1 while pndering/working on #3, perhaps? [03:12] 6- remove mailtos, add ML and Bugzilla search forms directly and prominently to feedback page [03:14] scop: that's one option, and I suppose it'd much improve the quality of feedback, but I am afraid it would make it "difficult" again to send feedback [03:15] my alleged goal here is to combine the two, but I may just be naive [03:16] to me #1 sounds more complicated than #6, given the need for challenge-response via mail for the 1st time [03:17] that could be done by the archive approval system, so we would not actually need to do that [03:18] scop: not sure I follow you. The user would get the challenge from the archive approval system in both cases, no? [03:19] besides, as I see it, #6 is pretty much included in #1 [03:19] #1 being #6 plus a mail form [03:20] yod, yes, but in #1 it's both web and mail; you already noted the non-intuitiveness of that [03:20] right [03:20] I see your point [03:22] for some reason the word "spam" is on my mind when I think about the web form [03:22] * yod wonders out loud whether a non-form based would still allow searching for specific error-message related mails [03:22] I guess yes [03:23] not spam to the list, but to other users... dunno if this is anything to worry about though [03:25] I suppose the feedback page, even without mail form, could be dynamic and have pre-filled search queries for given messages [03:25] ++ [03:25] And a sample email tog give users an idea of what to send (e.g. message number, URL, etc.). [03:34] is http://www.w3.org/Bugs/Public/show_bug.cgi?id=856 still/yet up to date wrt real known 0.7.0 blockers? [03:34] s/blockers/targets/ but as far as I know, yes [03:35] BTW, nice work on the bugfixes for check lately scop! [03:35] indeed, that was an impressive flow [03:36] thx, cosmetic stuff though... [03:44] regarding templates, shouldn't we do all url/html escaping of stuff there, not in check? [03:45] (all ~ "whenever we don't spit out markup from check") [03:46] Hmmm. Quite possibly. The idea of the templates is to get markup out of check; and escaping is markup, so... [03:47] Cripes but this thing is tiny! http://images.appleinsider.com/images/box.jpg [03:47] & and %xx are quite different though... [03:48] Hmmm. Yes, I was refering to the former, not necessarily the latter. [03:48] right [03:51] ...so no objections if I start moving markup escaping to templates, or do you think it's too intrusive change for 0.7.0 already? [03:53] If you have no qualms then I certainly won't object. :-) [03:53] hmm, no objection, as moving toward templates is, after all, the point of 0.7.0 [03:58] so... AFAICS things that require decisions before 0.7.0 can go beta are #838 and #915 [04:03] Add special note when UA is MSIE and type is text/plain, and close WONTFIX? [04:03] The UA might be removed by some proxy... [04:03] I'd rather Warn if type text/plain and treat as text/html [04:04] can check distinguish whether the content-type error comes from upload: or uri? [04:04] yes [04:09] No, I say we try to ignore it for a while. Iff we detect that this current error that we're about to emit is likely due to the MSIE bug, then tack on a warning to that effect. [04:09] No trying to treat plain text as HTML (MSFT can have that idiocy to themselves thankyouverymuch). [04:10] * bjoern_ notes that http://www.w3.org/TR/rdf-testcases/ requires to treat text/plain as N-Triples... [04:11] $msie_bug = $is_upload && $filename =~ /\.x?html?/i && $content_type eq "text/plain" [04:11] * yod has sympathy for IE users, but not too fond of quirky logic recovery mechanisms to compensate for IE's incapabilities [04:12] * bjoern_ has strong feelings that refusing to validate always gives poor user expierience and should be avoided [04:13] bjoern_ has a point [04:13] Well, there is the possibility of offering a Content-Type override... [04:13] ...which we we really should have for completeness for the fragment upload/text field input [later] [04:25] so #838, content-type override is the way to go? [04:26] Warning for current bug now, override at some point (possibly for 0.7.0) after. [04:29] warning as an immediate fix, would be really good if we could have content-type override very soon though, seeing as we also want to put text field validation back into the light... [04:34] override: Yes. I think this was coding-wise a reasonably easy thing to do; as I recall the worry was how to present it UI-wise and discourage misuse of the feature. [04:16] quick status check on badges: will they be there for 0.7.0, or are they being "phased out"? [04:18] the response to the first batch wasn't too bad, and the second batch is more in sync with what's needed, so I have hopes we can have them soon [04:19] * yod notes it was bjoern, not Comm, being most doubtful about the proposed badges [04:19] so if Bjoern is happy with most recent, we're on a good path [04:19] I'll update you on this topic as soon as possible