From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 7373A77D0D for ; Tue, 29 Dec 2015 11:57:04 -0800 (PST) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-06v.sys.comcast.net with comcast id zXvg1r00E2Ka2Q501XxU9l; Tue, 29 Dec 2015 19:57:28 +0000 Received: from eklhad ([IPv6:2601:405:4001:e487:21e:4fff:fec2:a0f1]) by resomta-ch2-11v.sys.comcast.net with comcast id zXxU1r0022MDcd701XxUPD; Tue, 29 Dec 2015 19:57:28 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke References: <20151229191702.GB1766@122oven.adamthompson.me.uk> User-Agent: edbrowse/3.6.0+ Date: Tue, 29 Dec 2015 14:57:27 -0500 Message-ID: <20151129145727.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=1451419048; bh=1kGNi3vBhxUaC5s46lXFtdDVNLT/NHd1naQHIgw1tA4=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=oPGDvCjIP8z54IA+egRCmw+jR+Alnfg4HmNQTlPcpvS1fLo9B0lHU0T+EC9HZu5DN NomdG/mB946ZPQI+NiXNWqKJNkTz1kXAExrnSPXrV4S/dZLRhNgO0pqZE3iygf3VH0 rsl3DsJ77BsaDUu9YYh1e8I9NIgGlWCqpHB76z/tsSnyewffyBymjYuU5q027vh2yd tBYTNfZNnXpmohg2Q9EqsF1fFlQIhYUmLhZWWMMSoQkSTTBab6884tJA35RPNlMxBp p3d9Aqng/8gWSGEBmfdSSYbV6iYm1VEECq8iWsVZURLocnxWDLN7VqshXC4ZQHoZOI 5Mo3sbI/hBxzA== Subject: [Edbrowse-dev] curl handles and general comms design X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2015 19:57:04 -0000 Yes, sorry if edbrowse is in a state of flux right now. I'm closing curl handles more as a proof of concept, not saying we need to or want to do that in general. Can we retain our cookie state with at least one handle open? We know about the sharing interface and Chris is going to work on that, and then all the handles should tie together with one cookie state and then some things should clear up. Some of the inefficiency could be rereading and rewriting the cookie file all the time, and that will go away. I put more of our state variables for downloading files etc on the stack in preparation for threads. I use to use static variables and got away with it since processes forked off, but we know that won't work so now moving to stacks in preparation for threads. This is the "curl http background download mini project" that we agreed on last week, and it should finish up soon and then we can talk about the next step. I'm thinking about an edbrowse-http process to handle these curl requests and maintain the one and only cookie state, but perhaps not just for edbrowse, perhaps for all instances of edbrowse running. I run edbrowse from various virtual consoles, sometimes without realizing it, and indeed one edbrowse could clobber cookies introduced by another edbrowse. I haven't noticed that specifically but it probably has happened. So if edbrowse-http became a daemon serving the curl needs of all edbrowse processes running, then that would solve any and all cookie collision problems forever more. Wonder if Chrome and others effectively share the cookie jar and favorites etc among separately running instances of the browser? Well it's something to think about. I also need to resurrect some of the socket routines that are buried in git, so we can use them. They're suppose to hide the differences between unix and windows, and they were tested at one time but that was like 15 years ago, so I'll want Geoff to look at them again. Send any bug reports or disasters to me, and hopefully this will stabilize soon. Cheers. Karl Dahlke