From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) by hurricane.the-brannons.com (Postfix) with ESMTPS id EED7777C75 for ; Tue, 23 Dec 2014 14:52:55 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-09v.sys.comcast.net with comcast id XAql1p0022JGN3p01AqoVn; Tue, 23 Dec 2014 22:50:48 +0000 Received: from eklhad ([68.84.191.77]) by resomta-ch2-10v.sys.comcast.net with comcast id XAqn1p00g1gep3001AqoH9; Tue, 23 Dec 2014 22:50:48 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.5.2 Date: Tue, 23 Dec 2014 17:50:47 -0500 Message-ID: <20141123175047.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419375048; bh=GF9+J1z/bQYyn1fuFlx8jik+HwrsgteiTkprPSPs2NM=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=ZBw5d1Mq6x+wP2nXLY1oRT4LhCtp11bIiCxaB8ZWKzqXeowa43GAcTPzr8NWXdd6R fr2WahRXbHDUrZ/EzzHza62sLrV3N30RPYsy5SXXXtkJzlLhossVjy8X56ep17Tbpr n71SHWgVACasCXsuF2nRwjZx4dfc2kcxeyeFoNzWAtnW3qokma8po0SUwjXfBKaQTp PTgruVKTbKtcmQyGxE3RDNhOIYpEevz4Y7qd/idkxRc0VxG87IHRtUk0YINgXfBpnF vpffcE7ciXeGLHWq5F9Rxd4VREDtCxc49VdAmTf6faClsZMc7NAhmJ1Y3orYVsomsm i1soQoeCMlC3A== Subject: [Edbrowse-dev] js engine process, version 1 X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 22:52:56 -0000 > it'd be nicer if the alert, prompt etc functions were done as part of the > protocol, letting edbrowse handle user interaction I think. Yeah I think so too, I was saving that for a future increment. > I don't see why this can't be done via ipc messages. I may not know enough, but I don't think ipc messages play nice with select, looking toward the day when we must monitor many input streams at the same time, many events coming in from many sources. You can select on many file descriptors, as I do in my adapter and other programs, but I don't think you can select on 4 file descriptors and an ipc message queue. If I'm wrong, we can switch from pipes to messages in the future, if it makes sense to do so. Probably not a big difference either way. Karl Dahlke