09:49
<micheil>
Hixie: are you about?
11:53
<Workshiva>
Re: the BBC article on Friday
11:53
<Workshiva>
"For this reason we are committed to the aims of HTML5. In combination with CSS3 and Javascript it promises a step forward for the web."
11:53
<Workshiva>
They actually managed to separate CSS3 from HTML5!
12:03
<annevk5>
oh my god
12:03
<annevk5>
Shelby Moore is back
12:03
<annevk5>
and it just got better
12:03
<annevk5>
"Let me confess that I have only been studying the entire issue of Comet,
12:03
<annevk5>
BOSH, WebSocket, and this mailing list, for a several hours. I came to
12:03
<annevk5>
this from Wikipedia, because I need to choose an architecture strategy for
12:03
<annevk5>
a social network I am developing. So take my comments as one perspective
12:03
<annevk5>
of an outsider (but an outsider with considerable experience in web
12:03
<annevk5>
development and successful commercial software both pre-internet and
12:03
<annevk5>
post). "
12:04
<Workshiva>
Several hours, impressive
12:05
<annevk5>
this stuff is great
12:05
<annevk5>
and he's already flooding the mailing list
12:06
<Workshiva>
I'm considering reading the public-html archives for July
12:09
<annevk5>
"Sorry to drop a Snicker bar in the swimming pool. Maybe someone can set me straight."
12:11
<annevk5>
context
12:11
<annevk5>
http://ln.hixie.ch/?start=1132620717&count=1
12:12
<annevk5>
http://ln.hixie.ch/?start=1041735552&count=1
12:12
<Workshiva>
It wasn't Snickers
12:12
<Workshiva>
I wish people would keep their references straight
12:12
<annevk5>
http://www.glazman.org/weblog/newarchive/2003_01_05_glazblogarc.html#s87008479
12:13
<Workshiva>
Commenting on people's names and it's only the second paragraph... hoo boy
12:15
<Ms2ger>
"This really has to end some time, but I will reply again in detail"
12:15
<Ms2ger>
Now that's a gem.
12:15
<annevk5>
I quite like the one about how he works well in multiple dimensions
12:15
<annevk5>
or when the epiphany happens in your mind
12:15
<Workshiva>
'Conflated'
12:17
<Workshiva>
<princess bride quote/>
12:18
<Workshiva>
So did he ever release Cool Page 4?
12:20
<annevk5>
does it matter?
12:20
<annevk5>
he's obviously amazing
12:21
<annevk5>
anyway, boarding time
12:21
<Workshiva>
Well, if it's as cool as he says, I want to use it!
12:21
<Ms2ger>
Hmm, I missed http://www.ietf.org/mail-archive/web/hybi/current/msg03198.html
12:24
<Workshiva>
http://www.cssquirrel.com/comic/?comic=66
13:17
<gsnedders>
jgraham: Yay! Applying a SEP field worked!
13:19
<Workshiva>
Eventually you ascend beyond applying to a SEP to considering powering the actual field to be SEP
13:19
gsnedders
isn't sure his head can think such things yet today
13:21
<Ms2ger>
Make thinking about it a SEP?
13:23
<Workshiva>
This talk about meta charset=utf-16 (yes, I'm a month behind) seems like an accident waiting to happen
13:30
<Workshiva>
"@srcdoc, for the first time, introduces HTML markup into attribute values. This is bad design."
13:30
<Workshiva>
But the alternative solution, using data: URLs, is of course completely cool
13:33
<Philip`>
A data: URI isn't markup, it's an identifier of a resource representation that contains markup
13:34
<Philip`>
Totally different things
13:34
<Workshiva>
Of course
13:34
<Workshiva>
That's why it's completely cool
13:35
<Workshiva>
Wow, that's a lot of mail about @alt in private email
13:45
Workshiva
wonders how the mimeheads expect servers to be configured to provide correct audio and video codec subparameters in content-type without looking at the file contents
13:49
<jcranmer>
Workshiva: file ?
13:50
<Workshiva>
jcranmer: ?
13:51
<jcranmer>
use the file program
13:51
<jcranmer>
yes it looks at file contents, but you can assume it's a black box
13:51
<jcranmer>
and plead operational ig
13:51
<jcranmer>
norancce
13:51
<Workshiva>
Sure, but that's still sniffing
13:52
<jcranmer>
either that, or you require that the filename contains the codec in there
13:53
<Philip`>
Store the files with metadata
13:53
<Philip`>
either in the filesystem or in a database or something
13:54
<erlehmann>
use file extension :P
13:54
<Philip`>
rather than sticking with the boring old primitive view that one URL = one file on the disk
13:54
<Workshiva>
Well, you can replace file with resource representation
13:55
<Philip`>
The representation already has content-type metdata so there's no problem from that point
13:55
<Workshiva>
We're at the stage where the server is trying to decide what to emit
14:49
<erlehmann>
Is there a test suite for serving media files? I figured out I had to handle range-requests and send an X-Content-Duration request but am unsure if my ad-hoc webserver is doing it right.
14:50
<erlehmann>
And having curl as your only validation tool is kinda weak.
14:50
<Workshiva>
Try redbot.org
14:58
<erlehmann>
thx, interesting.
15:08
<erlehmann>
My content-lenght is 248 bytes too long. Everytime.
15:08
<erlehmann>
o.0
15:58
<micheil>
hmm... anne's not here anymore?
16:00
<Ms2ger>
<annevk5> anyway, boarding time
16:01
<micheil>
k, I didn't see the part message
16:02
<micheil>
hmm.. Is someone trying to change the WebSocket protocol further away from where it was starting to head?
16:02
<micheil>
or, rather proposing a different client-side API?
16:05
<jgraham>
micheil: no to the secod part. Possiblyt to the first part depending on what you meant
16:05
<micheil>
well, what's that thing on the hybi list about a) sendTextMessage(char []buffer, int offset, int length); // JavaScript 16-bit text send
16:06
<micheil>
because the one thing I constantly hear from developers is how easy the client side websocket API is to work with.
16:06
<jgraham>
micheil: I think that was not about the js-api
16:07
<micheil>
I actually have a proposal for the client-side api (which is/should be backwards compatible), if we do get a consensus on the binary sending of data
16:07
<jgraham>
It was examples of possible api styles in general
16:07
<jgraham>
People seem to be interested in non-js clients
16:07
<micheil>
I'm thinking to indicate binary data, you would add on a second argument
16:07
<micheil>
there should be one client side api.
16:08
<micheil>
no matter what. Because really, why would you need to change it.
16:08
<jgraham>
micheil: If you build e.g. a python client the api will likely look different
16:08
<micheil>
not really
16:09
<jgraham>
micheil: Well python code is not necessarily evented
16:09
<jgraham>
depending on what you are doing
16:09
<micheil>
well, the sending on a websocket isn't evented at all.
16:09
<gsnedders>
To take a more extreme example, a Haskell impl would likely be even more radical
16:09
<micheil>
it's actually blocking, iirc.
16:09
<jgraham>
Receiving is also part of the api
16:09
<micheil>
okay, true, functional programming languages would be different, but an object oriented or similar language would not
16:10
<micheil>
true
16:10
<jgraham>
Anyway, in the js case, you don't need any parameters to indicate binary or not
16:10
<gsnedders>
jgraham: (please don't murder me for mentioning Haskell)
16:10
<micheil>
yeah, you could use typeof
16:10
<jgraham>
gsnedders: What? You make no sense
16:10
<micheil>
(and similar methods)
16:10
<gsnedders>
jgraham: Well every time I've mentioned Haskell on IRC with you around recently…
16:10
<jgraham>
micheil: in the implementation you just have send(data)
16:11
<jgraham>
and if data is a String you make a text frame and if it is a Blob you make a binary frame
16:11
<micheil>
currently a thing we do in node.js, is that in order to send non-utf8 data but by storing it as a string, we do something like:
16:11
<jgraham>
s/Blob/BinaryArray/ or whatever
16:11
<jgraham>
gsnedders: You still make no sense
16:11
<micheil>
socket.write("\xff", "binary");
16:11
<jgraham>
All I have said is that Haskell has a steep learning curve
16:11
<micheil>
if the second argument is blank, I believe it'll actually default to UTF8
16:12
<micheil>
or ascii
16:12
<jgraham>
gsnedders: Why I would murder you because of that fact is not at all clear
16:12
<micheil>
which ever is the default set by socket.setEncoding
16:12
<jgraham>
I don't evcen think it is a controversial statement
16:14
<micheil>
annevk5: moin.
16:14
<annevk5>
hey hey
16:15
<annevk5>
discussion on list is about the wire format (well, apart from the current Shelby Moore entertainment)
16:15
<annevk5>
the API is unlikely to be affected
16:15
<micheil>
what's with that, any way?
16:16
<annevk5>
the wire format?
16:16
<annevk5>
it seems like we will get something more complicated
16:17
<micheil>
currently I'm really liking the direction of having a length indicator
16:17
<annevk5>
mostly due to Google
16:17
<annevk5>
sure
16:17
<micheil>
perhaps have two length indicators? The first which is the metadata length, the second which is the message length
16:17
<micheil>
if that's part of the issue?
16:22
<micheil>
annevk5: what's the issue google has with the protocol?
16:25
<annevk5>
they want more features in the initial version essentially
16:26
<annevk5>
gotta run
16:26
<micheil>
ouch
16:26
<micheil>
is there a list of these features?
17:27
<henrikbjorn>
from what i understand in the spec a <article> dosent have to includ a <header> is that right ?
17:30
<Ms2ger>
Sounds right
17:30
<Ms2ger>
You'll probably want a h1, though
18:24
<henrikbjorn>
Ms2ger: the problem is the article is a comment and comments dont have a headline
18:24
<Ms2ger>
Then I guess it's fine