01:41
<Cheery>
Now I have an easy-to-use websocket library written in python
01:41
<Cheery>
http://hg.boxbase.org/websocket
01:43
<Cheery>
I'll yet write a simple chat using that program.
01:43
<Cheery>
(there's small example around though)
01:44
<Cheery>
I've got no issue -listing system, send them to my email.
02:34
<GPHemsley>
This might be of interest to the folks in here: http://www.govtrack.us/congress/bill.xpd?bill=s111-3304
02:36
<MikeSmithX>
"Sets forth provisions concerning closed captioning decoder and video description capability, user interfaces, and video programming guides and menus."
02:37
<MikeSmith>
Cheery: very cool to see you got the websocket library written
02:37
<Cheery>
I did already a little chat server on top of it.
02:38
<Cheery>
little hacky though. :/
02:38
<Cheery>
(could do a better one eventually. ^^)
02:40
<Cheery>
http://paste.pocoo.org/show/239236
02:40
<Cheery>
http://paste.pocoo.org/show/239237
02:43
<Cheery>
MikeSmith: yeah. though it could be easier you know.
02:43
<Cheery>
likely have to provide alternative listener for non-websocket activity
02:44
<Cheery>
there's one thing I don't understand.
02:44
<Cheery>
why do we write our software backwards compatible?
02:45
<Cheery>
in a way that we'll gather little of complexity from older systems while moving to newer ones.
02:45
<Cheery>
obviously there's things that need to stay like they are, because we use them too much.
02:46
<Cheery>
like networking stack.
02:46
<Cheery>
or filesystems and filehandles
02:46
<Cheery>
and by part those aren't even bad, they make software simpler
02:47
<Cheery>
but then there's things like windows and X11
02:47
<Cheery>
or python
02:47
<Cheery>
or javascript
02:47
<Cheery>
about in 3 years opengl joins the club.
02:49
<Cheery>
browser is like an another operating system in our desktops.
02:50
<Cheery>
about everyone knew that two years ago.
02:53
<Cheery>
only move there's been is the chrome OS
02:56
<Cheery>
it's even sillier that the major software industries sit in the shit like they'd be glued into it.
02:57
<Cheery>
or then they introduce things that just become the next silly fadshit of the future.
02:57
<Cheery>
like MS silverlight
02:58
<Cheery>
though maybe it's meant that way.
02:59
<Cheery>
closed source software doesn't have place in a world that requires better performing software every day instead of tens of years.
04:22
<gsnedders>
When doing IPC in Perl, is using SIGALRM within an eval the nicest way to do timeouts?
04:32
<boblet>
Hixie & foolip: Thinking about the magic n optimisation etc in µF hCard, I think the microdata vcard vocabulary shouldn’t use http://microformats.org/profile/hcard as it’s vocabulary URL if it differs from hCard
04:34
<boblet>
I’d assume given the microformats.org url that microdata vcard would be 1:1 with hcard (rather than vcard) and include hCard changes to vcard. hopefully this will be resolved with hCard 1.0.1
04:36
<boblet>
in the meantime seeing as the vocabulary is included mainly as an example of writing a microdata vocabulary, it might be worthwhile to include hCard’s quirks to demonstrate they can be accommodated. that or changing the itemtype URL and other hcard references…
09:33
<hsivonen>
Hixie: is the lack of cache-control support in meta pragmas by design?
12:21
<phrearch>
hi
12:21
<phrearch>
im using websockets now for im, but i wonder whether it would be faster to do all json related stuff over websockets
12:21
<phrearch>
currently, page-loading in this webportal is still done with xhr
13:01
<Cheery>
ookay. I've got a websocket-powered chat up in: http://boxbase.org/fun/simplechat/
13:01
<micheil>
neat
13:01
<Cheery>
going to remove it in few hours though.
13:01
<micheil>
server?
13:01
<Cheery>
micheil: server?
13:01
<micheil>
Cheery: is it a custom server implementation, or a library?
13:02
<micheil>
also, is it only doing draft76?
13:02
<Cheery>
http://hg.boxbase.org/websocket
13:02
<hsivonen>
Cheery: doesn't work for me on Firefox trunk
13:03
<Cheery>
hsivonen: what's your IP?
13:03
<hsivonen>
Cheery: looks like you've forgotten a reference to 'console' to production code
13:03
<micheil>
it's draft 76 only.
13:03
<micheil>
so, people using Safari 5 will not be able to connect
13:04
<zcorpan_>
Cheery: doesn't work for me either
13:04
<Cheery>
hmm..
13:04
<zcorpan_>
hmm works in chrome dev
13:04
<zcorpan_>
but not in firefox or opera (internal)
13:04
<hsivonen>
IIRC, the console object exists in WebKit-based browsers
13:05
<micheil>
zcorpan_: which version of websockets does opera support?
13:05
<hsivonen>
but not in Firefox (without Firebug)
13:05
<jgraham>
Cheery: addEventListener needs 3 parameters
13:05
<zcorpan_>
actually i can receive messages in opera but not send
13:05
<zcorpan_>
micheil: 76
13:05
<micheil>
zcorpan_: I'd like to update my table of browser support, if possible.
13:05
<Cheery>
jgraham: oh yeah.. forgotten. fixing ^^
13:05
<micheil>
zcorpan_: can I place it here: http://wiki.github.com/miksago/node-websocket-server/browser-support ?
13:06
<zcorpan_>
micheil: it's an internal build, so for public purposes opera does not support websockets yet
13:06
<micheil>
okay
13:06
<micheil>
well, I could do like I've got firefox 4 there.
13:07
<micheil>
with the footnote saying that it's to be released / being worked on
13:07
<Rik`>
hsivonen: the plan is to have the console API inside Firefox 4 I think
13:07
<zcorpan_>
micheil: just don't say it'll be in the next version since that's not a given :)
13:07
<hsivonen>
Rik`: yeah, but it's not there yet, apparently
13:07
<zcorpan_>
micheil: i'm fine with it saying it's WIP and it's -76
13:08
<hsivonen>
in retrospect, navigator.console would have been nicer
13:08
<hsivonen>
less global scope pollution...
13:09
<Cheery>
I wrote the server based on this stuff: http://www.whatwg.org/specs/web-apps/current-work/complete/network.html#server-side-requirements
13:09
<micheil>
zcorpan_: I'll just say: "Opera is currently working on implementing websockets
13:09
<zcorpan_>
ok
13:11
<micheil>
zcorpan_: this ok? http://wiki.github.com/miksago/node-websocket-server/browser-support
13:11
<micheil>
zcorpan_: if you have a github account, then, feel free to edit that page.
13:11
<zcorpan_>
micheil: looks good
13:11
<micheil>
okay
13:13
<zcorpan_>
Cheery: feature check for console before using it
13:13
<Cheery>
zcorpan_: feature check?
13:14
<hsivonen>
Cheery: if (console) { /* do stuff with console */ }
13:14
<micheil>
if( console && console.log)
13:14
<Cheery>
oh yeah!
13:14
<hallvors>
if( window.console && console.log )
13:15
<hallvors>
is better, otherwise "if(console)" will cause exception
13:15
<micheil>
shouldn't if it's undefined
13:15
<zcorpan_>
yes it should
13:15
<hallvors>
micheil: if there is no variable "console" it should throw
13:15
<micheil>
hmm.. fair enough
13:16
<hallvors>
what's the best version to see what changes happened to a specific part of the HTML5 spec?
13:16
<Cheery>
so some of your systems drop into the missing console?
13:16
<Cheery>
hm..
13:16
<hallvors>
um, what's the best *way* to see what changed in a specific part of the spec?
13:16
<zcorpan_>
Cheery: also i'd send the message onsubmit on a parent <form> instead of onkeypress
13:16
<Cheery>
I'll fix that
13:17
<jgraham>
hallvors: That is quite difficult in general
13:17
<jgraham>
What is your specific problem?
13:18
<hallvors>
jgraham: it's a common use case though :p
13:19
<hallvors>
Actually, I'm looking at an E-mail from Adam Barth on postMessage. He says "The implementations were compatible with the spec when the
13:19
<hallvors>
implementations were written, as far as I remember" so I'd like to check if this is true
13:19
<jgraham>
hallvors: Well it's a slightly ill defined problem so it isn't trivial to make a solution
13:20
<hallvors>
in other words, when was postMessage() targetOrigin specified and when did the spec state it should be protocol+hostname [+port] without path?
13:20
<zcorpan_>
hallvors: go to http://html5.org/tools/web-apps-tracker and add ?limit=2000 (or so) and search for postMessage or targetOrigin
13:21
<jgraham>
hallvors: Either use the webapps tracker to look through the log
13:21
<jgraham>
or check out the spec from the right date using svn
13:22
<jgraham>
Cheery: Might wfm now
13:23
<Cheery>
I'll need to do something for this console stuff. somehow it's now working for you. :)
13:23
<Cheery>
well, now it's good.
13:25
<Cheery>
jgraham: my server received your message, it seems.
13:26
<jgraham>
Cheery: OK, does wfm then
13:28
<Cheery>
want me to publish the log? (though should I first remove all the IPs from it?)
13:33
<Cheery>
okay.. there's few weird things here.
13:34
<Cheery>
if I don't send a message to the server, it is unable to push me *anything* at all. :o
13:40
<Cheery>
the server looks like this: http://pastebin.com/8p64Um1P
13:48
<Cheery>
there's one weird thing in my system though.
13:49
<Cheery>
my friend says TCP ought not behave the way it just did
13:49
<Cheery>
the server should be able to push along that connection
13:49
<MikeSmith>
wow, cool to see hallvors on #whatwg IRC
13:56
<Cheery>
closing the server
13:56
<Cheery>
not good experiences. :/
13:56
<Cheery>
though I still only implemented a draft from it.
13:59
<foolip>
roc, there?
14:03
<Cheery>
jgraham or zcorpan_: so, is my system working up to the spec?
14:03
<Cheery>
(or am I missing something important there?)
14:03
<Cheery>
some of the header retrieved didn't have websocket key. :/
14:04
<Cheery>
at another point my program spotted a lacking '\x00'
14:04
<Cheery>
from message
14:05
<roc>
foolip: yes
14:06
<foolip>
roc, just wondering why "Mozilla" has seemingly changed its mind on application/octet-stream
14:06
<foolip>
perhaps my memory is incomplete
14:06
<roc>
you guys convinced me you were right
14:06
<foolip>
oh, what did we say?
14:06
<foolip>
hehe
14:06
<roc>
we need to support sniffing for the case where there is no Content-Type
14:07
<foolip>
is there a problem with just not playing resources with missing Content-Type?
14:07
<roc>
there is no reason not to sniff when application/octet-stream is the Content-Type too
14:07
<phrearch>
hey
14:07
<phrearch>
got a websocket chat as well
14:07
<roc>
there's a race-to-the-bottom problem given that Safari and Quicktime sniff and they're not going to stop doing that
14:08
<Cheery>
phrearch: how does your websocket chat fare?
14:08
<foolip>
do they also play text/plain then?
14:08
<roc>
I don't know
14:09
<roc>
I think so
14:09
<foolip>
as long as Safari doesn't play Ogg/WebM it's unlikely to cause compat issues though
14:09
<foolip>
so, I guess I still don't have a strong opinions, but would like things to be consistent
14:09
<phrearch>
Cheery: its still a very basic chat
14:10
<Cheery>
when did you write it?
14:10
<roc>
sure
14:10
<phrearch>
a week ago using twisted as webserver
14:11
<Cheery>
how did it worked on different systems?
14:11
<foolip>
so, I'll wait for your reply to Julian and perhaps some more and then decide what to do with this
14:11
<phrearch>
ehm, only tested on chromium 5
14:11
<phrearch>
https://simstad.nl/
14:11
<phrearch>
not sure if that version is setup right
14:11
<phrearch>
http://hwios.org/browser/hwios
14:11
<phrearch>
thats the source
14:12
<micheil>
since we're sharing, here's mine: http://brandedcode.com:8000/
14:12
<micheil>
written in Node.js, supports draft76 & draft75
14:13
<phrearch>
cool
14:13
<micheil>
and the source code: http://github.com/miksago/node-websocket-server/blob/development/examples/chat-server.js
14:14
<micheil>
that's the chat specific stuff, in http://github.com/miksago/node-websocket-server/blob/development/lib/
14:14
<micheil>
is the actual server stuff
14:14
<micheil>
turns out serving http on a websocket server is also actually quite a good idea
14:17
<phrearch>
it is?
14:17
<phrearch>
im doubting between keep on using xhr with html over json for page loading or use websockets for that as well
14:17
<Cheery>
micheil: a question: where do I find the draft76 and 75?
14:18
<Cheery>
(specs)
14:18
<micheil>
on the ietf site
14:18
<phrearch>
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76
14:21
<phrearch>
ok messenger works now on https://simstad.nl/
14:21
<phrearch>
anyone wants to test it quickly?
14:22
<Cheery>
phrearch: no action
14:22
<phrearch>
hm, what browser?
14:22
<phrearch>
it should work with chromium 5. im not sure if hixie 76 handshake works ok
14:23
<Cheery>
hmm..
14:23
<Cheery>
hixie 75 obsoletes in august
14:24
<phrearch>
with twisted its not difficult to change the handshake mechanism
14:24
<phrearch>
it has .76 but i think chromium 5 still uses .75?
14:25
<micheil>
changed the address: http://brandedcode.com:8080/
14:25
<micheil>
phrearch: http://wiki.github.com/miksago/node-websocket-server/browser-support
14:26
<Cheery>
phrearch: chromium 6 uses 76
14:26
<phrearch>
aha ok
14:26
<phrearch>
76 probably doesnt work right
14:27
<phrearch>
the server handshake on my server that is
14:27
<Cheery>
the weird thing.
14:27
<Cheery>
I've got both chromium 5 and 6 on my machine
14:27
<Cheery>
the chromium 5 doesn't even connect!
14:27
<Cheery>
(with websocket stuff it has)
14:27
<phrearch>
wow. who planted an image in the chat window?
14:28
<Cheery>
what image?
14:28
<Cheery>
missed it. :/
14:28
<phrearch>
ehm on http://brandedcode.com:8080/
14:29
<phrearch>
regexp are nice to add smileys
14:32
<phrearch>
im working on a remote ajax service console now. using websockets its much easier to do
14:34
<phrearch>
how are you guys dispatching events on the server?
14:36
<phrearch>
im using a jsonrpc handler serverside and a modified jquery websocket plugin for the client
16:57
davidb_
waves to clown_afk
16:57
<clown>
hi davidb_
17:37
<KaOSoFt>
http://www.jolicloud.com/blog/
17:37
<KaOSoFt>
:D
18:10
<jgraham>
Oh yay. HyBi spam
18:41
<florent>
Hi, I read this thread : http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023661.html, and I wonder if it (or something similar) is still in discussion or not ? (it seems to be given up)
18:51
<florent>
is my question not clear ? :(
18:53
<TabAtkins>
florent: It's been rejected, as it can be achieved with about a dozen lines of js code.
18:54
<florent>
ok, thanks TabAtkins
18:55
<florent>
I have proposal based on this idea, where can I send it ? (on the mailing list ? )
18:56
<florent>
(with other advantages)
18:56
<TabAtkins>
Just send it to whatwg⊙wo
18:56
<florent>
all right
18:57
<florent>
Thank you :)
20:48
<oal>
How can I prevent newlines in a contenteditable="true" div?
20:54
<oal>
Fixed it by using jquery and e.preventDefault() on a keypress event ;)
20:55
<jgraham>
I would carefully check how well that works cross browser
20:55
<oal>
Works in chromium and firefox
20:55
<jgraham>
You should be fine, but keypress events and contentEditable are not known for interoperability
20:56
<oal>
Don't have IE, but this isn't meant to work in older browsers
20:56
<jgraham>
oal: So only Opera and IE left to check :)
20:56
<oal>
jgraham, yep, I have opera installed, will check later :)
20:58
<oal>
jgraham, ok, works as expected in Opera too
20:58
<Philip`>
oal: That sounds like it won't work if the pastes a multi-line string
20:59
<oal>
Philip`, hmm, true, let's check
20:59
<oal>
Philip`, you're right. Hmm
21:00
<oal>
I can remove line breaks when the data is submitted too, to make sure no line breaks are in
21:00
<zcorpan_>
why are you using contenteditable instead of <input>?
21:00
<oal>
Hmm, and maybe a setInterval to check and remove line breaks
21:00
<oal>
zcorpan_, to get the correct styles
21:01
<zcorpan_>
oal: can't you style an <input> to inherit the correct styles?
21:02
<oal>
zcorpan_, probably, but in this case contenteditable does the trick :) Also I'd like to learn how contenteditable works
21:02
<zcorpan_>
ok. i think <input> is a better solution in the end :)
21:03
<oal>
zcorpan_, I can always change the code if that is the case :)