From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 0C88477C94 for ; Sun, 16 Jul 2017 19:03:10 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id WvNAdqEPw4QqNWvNOd2dGw; Mon, 17 Jul 2017 02:03:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1500256990; bh=gPOHpid5g8EYDi2D0E+9vno90gsHQeqfUD/SSHtWsQE=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=dZdBqG9O7zvzag6DmRHfB+8J1AG0RQFPEQZSPlgjFzuCC32ZqPJf4UQ9jxYEAoeoi Buhp5mGSBFR77IJtIeWM8I+Yvi7hwT5vXIt/HFB/oWTrmSDm6Sdt2uuo4Qxg8A3ysi RVAoAnWUKWgCkqPNGOf5eEhQbnf1a3wTQN5ztMoof1rmBEpbGL50B3w3HFdiRP1JOT BcdxK/dmzpvmPmilaz5tEtf1qgQJvCgEb+ZMEr7QTNkgZBn1EUWH8U00KwmK2T3QQ+ b4s8ZiCHsxMxiYMei8YEyqonaQ8ehzvuBOF/P8U4eoiZjneVIdKP9KCbruC0vjFBeZ 0wo4UjyrhLdbg== Received: from unknown ([IPv6:2601:408:c301:784d:21e:4fff:fec2:a0f1]) by resomta-ch2-05v.sys.comcast.net with SMTP id WvNNdMv2DWEpEWvNOdxsjb; Mon, 17 Jul 2017 02:03:10 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.7.0x Date: Sun, 16 Jul 2017 22:03:09 -0400 Message-ID: <20170616220309.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-247637 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGAug9jsDkgYgnqSpiZyjhod8ewOJHVUXKhsCD+eyYZ0f74/xEqHaBFDaKCLhklS/3lK7FwiYuq9csrlwL0GiI0pOZN0wiv8lEpeXcRTkQ95/XfWvVgp XW4xYub31lZ5iEpxq9am2YKlsnI6ukexeIKqCWcmhCPp2NsDmSCcQpY6 Subject: [Edbrowse-dev] The Ongoing Cookie Saga X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.24 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2017 02:03:11 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --nextpart-eb-247637 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable For 2 or 3 weeks I've been working on the duktape conversion, and for = all that time I've had the API web page up in console 6. Any question I have about what to call or what it does I switch to = console 6 and read about it, then switch back. Then after 3 weeks I'm done and I exit the API page and close that = instance of edbrowse. What does that do? Writes the cookie file as it was 3 weeks earlier. All cookies that might have accrued during those 3 weeks are gone. Poof! This is something we've talked about before, but this incident really = brought it to the fore. The strategy was always to spin off an edbrowse curl process to be our = curl server, and all user instances of edbrowse would talk to it, and = it would manage the cookies in one central place, and so on. I laid out some interprocess messages to and from the curl server, and = I just recovered those from the archives, just for grins. Around February of last year if you're interested, thread "Messages to = and from edbrowse-curl". But there are things we didn't even get round to talking about, like = how that process probably has to be multithreaded with one thread per user edbrowse process, so one slow http connection = doesn't bog down the other processes, and how to implement the interprocess messages in a unix window = portable manner, and how to start the edbrowse curl process, and how then everybody = communicates with it, and how it remains efficient even for large downloads, and how they can = happen in the background as they do today, and when will it write the cookie file (since it never exits), and how to pass changing config options from user processes over to the = curl process (such as the NTLM toggle and others), and on and on. In other words it's a huge amount of work. I knew it was a lot before but now I see it's more, like would take 6 = months of my full time effort, and the result would be some pretty fragile and confusing code that I = probably wouldn't like anyways. Anybody who had to maintain or enhance it would probably cuss me out. As Fegin said in Oliver, "I think I'd better think it out again." Or as Karl says from time to time, "A moment of thought is worth a = megabyte of programming." How bout this instead? It's like 0.1% the effort. Just before curl closes down, which is when it writes out the cookie = file, read the cookie file in again, and incorporate any new cookies, or any = cookies whose expiration date exceeds the date of the cookie we have = internally. Then exit, and curl writes the cookie file as usual, with all current = cookies. It's a merge of what we know plus what's in the jar. We have written most of this code already. I read the cookie jar at edbrowse startup, and I have code to check for = a duplicate cookie, but I just take the second one instead of comparing = the expire times. Well that's a pretty small change. Overall I think it would be easy peasy lemon squeezy, and would solve = the problem. Thoughts? If I were to work on this would you want me to switch back to the = master branch - it has nothing to do with duktape or js. Karl Dahlke --nextpart-eb-247637--