From mboxrd@z Thu Jan 1 00:00:00 1970 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 EFCE1779C1 for ; Sun, 25 Aug 2019 12:16:35 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-09v.sys.comcast.net with ESMTP id 1xxRip7D8SZzk1y0AiYfFv; Sun, 25 Aug 2019 19:16:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1566760594; bh=niKN7r3DWPacDa2mordh52/7yWMGQOiZG/C21GNEbCE=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=OXbetQEC8WG1pOWqe+gmMvZfwctt+T+VZBsGWa9bQtxri6x+XzgkEqOlWqyHB0pU0 s5a9V3sZ5rQ9RehyuO4b/Gd3Oq3ZUuqRFW9dXuBzNob9bysaB4LQcKkB4bN0zt5RME 0E7vs0G7pncT4R3M208/D0V83qgROQJV6iN7JP8cW5K+XzzbLkAjjnDV38GnXL31Xy ihq86I+MHPVd4HMl2uqv175NiEegw3vXfndaxgwFuvRL1HB5LnMpW2Vaap0PlTohFv xBTFCsY6wA3K3OpLxvA534TX64f3VqKczM3APGw6U6xflzqGNR3gBiF3DkdrT8MMUs SayLRKx9Pwo4g== Received: from unknown ([IPv6:2601:408:c303:3f49:21e:4fff:fec2:a0f1]) by resomta-ch2-18v.sys.comcast.net with ESMTPSA id 1y09iLhLI5PpO1y0Aiw3zo; Sun, 25 Aug 2019 19:16:34 +0000 X-Xfinity-VMeta: sc=0;st=legit To:edbrowse-dev@edbrowse.org From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E) Subject: [edbrowse-dev] Fun Things to do Date: Sun, 25 Aug 2019 15:16:33 -0400 Message-ID: <20190725151633.eklhad@comcast.net> X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-571304 Content-Transfer-Encoding: 7bit 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-571304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable * Often you go from one page to the next to the next on a website, all = calling the same js and css files. Yes, we issue a head request then pull them out of cash, which is = pretty good, but they're already in edbrowse, and these pages are very = static, so if we pulled or verified the page within the past few hours, it's probably fine to use the same data that is already sitting in the = parent page. Would save time and also space. If more than a few hours then ok issue the head request and confirm, = but then point to the earlier data. We should reuse it at the c and javascript levels. Implement a new mini-cache at the end of the file cache.c, apart from = the disk cache, only for js and css files, and have we seen this and if = yes we are holdlding the data, and ongoing script tags can use this as = their script data, and we can put it in mw0 on the js side and the javascript tags = script.data can point to it. * Download large files in background, and the experimental downloading = of all the js and css files in background and in parallel, which all = modern browsers do, because it speeds things up especially for a new uncached website, we do this by forking processes which is bad at many levels. So bad that it doesn't work (for https) at all under gnutls, though it = does work under openssl. We neeed to convert all this to threads. I'm not worried about windows any more, so we only need understand the = standard unix thread manager. Anyone feel like tackling one of these? Karl Dahlke --nextpart-eb-571304--