> Pipes, sockets or message queues would be the three I'd think of here.
Right. Probably pipes cause it's easy, but it mostly doesn't matter and could be easily changed one to another. > how would this play with blocking calls, All three of these, and any others you might think of, block by default, and can also be set nonblocking, but I've learned over the years nonblocking is a bad idea. Never make a nonblocking call. My jupiter speech adapter for example - reads index markers coming back from the synthesizer asynchronously, and your keyboard commands, perhaps telling speech to shut up, and maybe speech commands coming from other processes through the fifo /etc/jupiter.fifo. Three asynchronous streams to monitor simultaneously, and the right way to do this is by calling select. In other words, if a primary process is monitoring many asynchronous events from other processes / streams, select() is your friend. It does exactly what you want. This is deep in the kernel, and thank god they put it there, because you just can't simulate it through any kind of user space programming. Anyways, I believe we will be able to migrate to various asynchronous events, ajax, download to disk in background, etc etc, when the time comes. I will see if I can bang this first step out, partly because I haven't programmed in about a year, and I find that I really miss it. When you're not programming for your boss / professor, it really is fun. I estimate a couple of weeks. Meantime you (plural) might look at v8 and just evaluate. I still haven't gotten a hello world program to compile, and honestly that concerns me. Much of their documentation is all excited about setting speed records, and compiling js code into native cpu code for speed. Really? A true js compiler? What the fuck for? To see how fast you can jerk off? As we've said so many times, performance is not really an issue here, how about reliability and portability and flexibility? The last thing I'd want to do is turn js into machine code. Well google sometimes does things just to do them, just because they can. Still it looks like a cleaner interface, without all the compartment confusion, and I'm sure those compartments are really going to haunt us when one js context travels through document.frames[2].whatever to access another context. We don't do this stuff now and we need to and I'm not sure how to cross into the other compartments and honestly I'm not sure how firefox does it eithere, but it must. I'm thinking intercontext stuff is easier in v8. But I really don't have a clue. Anyways, I'll get back to my ipc work, which is moving forward nicely. Chris, as maintainer you might want to ask if we should mark another version before taking the ipc step. I think there were just little tweaks here and there since 3.5.1, but some of them fixed some small bugs. Look at logs and see what you think. Karl Dahlke _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
