From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 960617891C for ; Sun, 30 Aug 2015 04:41:34 -0700 (PDT) Received: by wicpl12 with SMTP id pl12so4884978wic.1 for ; Sun, 30 Aug 2015 04:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=OqtdJjaugHLTZBJKFzkWzPefoHfmMn9E6SX1i7owYPE=; b=gPr4UvZZbQXYcP5hkjTpogkZ+ndvdgiMK4SfyK2ORP1Of+odTMfdTNfH1qPEKJwBFS ZgKGgMFH/gJ15CnKc9B/of14Ne637XbtkqS9eybKguu0/VK4ixiVEqblaq/yyAr7bqJe D7PUV1M6FhRdeum2N0NQjzhIcYjvOCfBav8Asnp4NKXaPO2ZiCNKgN+O0oH1+HnCxiMq udFKXaZzvJBrFZ5dWWFHuDgvEkyalKlO7Fwcmtll9N55YkBAMGTuQx3iDjhAyY6E89jR E1a1d7FqCiyY398fj+HG9bzk2hLQ7BXltbuT+L4lvxRwvXHXC9Kb+lgEXZ9J292ykO02 MGcw== X-Received: by 10.180.39.172 with SMTP id q12mr14111820wik.17.1440935027077; Sun, 30 Aug 2015 04:43:47 -0700 (PDT) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by smtp.gmail.com with ESMTPSA id lj2sm12534855wic.1.2015.08.30.04.43.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Aug 2015 04:43:45 -0700 (PDT) Date: Sun, 30 Aug 2015 12:43:43 +0100 From: Adam Thompson To: Karl Dahlke Cc: Edbrowse-dev@lists.the-brannons.com Message-ID: <20150830114343.GB23730@toaster.adamthompson.me.uk> References: <20150730073107.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QTprm0S8XgL7H0Dt" Content-Disposition: inline In-Reply-To: <20150730073107.eklhad@comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [Edbrowse-dev] parser separation 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: Sun, 30 Aug 2015 11:41:35 -0000 --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 30, 2015 at 07:31:07AM -0400, Karl Dahlke wrote: > I was thinking about the history of our js interactions. > We felt it was wise to separate and encapsulate, > writing jseng-moz.cpp as a separate source file running a separate proces= s. > Among other benefits, > this makes it easier to switch engines, or conform to Mozilla upgrades > and changing APIs. > We've talked about v8 and duktape for instance. > Those are still possibilities. > So ... if there is any uncertainty at all about the html parser, > or if we just want to keep the door open, should we do some encapsulation, > and should we start now? Yes. > The connection is far simpler than js. > Pass html text, get back a tree of nodes. > It's conceptually a function call, > and doesn't need to be a separate process or thread. > Nothing asynchronous etc, and no ongoing dialog with states etc. > So it's very simple, but still might be worth putting in another sourcefi= le. >=20 > html-tidy.c - use tidy to parse html > html-hub.c - use hubbub to parse html > ... Still not sold on hubbub. Can you actually get it to build without building netsurf, or find any documentation on it for that matter? If we can then yeah we can look at it also, that'd be potentially better, but it seems to have disappeared as a separate project and I don't want edbrowse to be bound to netsurf's development. I know when I looked I couldn't extract libhubbub any more and the distro package has gone. > Let the makefile link in whichever one we want, > just as the makefile determines mozilla or v8 or duktape etc. > Then htmltidy.c is the only file that needs tidy.h and its > structures and API, and it returns to us > a tree of our nodes, as converted from the tidy nodes, > which we then use to build our DOM. > It's a small bit of administrative overhead that might pay dividends. > What do you think? I think that we probably want to also create a library of common functions = for working with the node tree in that case. That'd essentially be a DOM, with the only work then being to create the re= st of the objects it requires, and expose it to js... oh and alter the rendering... and bug squash. Cheers, Adam. --QTprm0S8XgL7H0Dt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJV4uxvAAoJELZ22lNQBzHOMWAH/1U/UlxzrQI0z+CrSaVzthKZ WTf1xIcfJASVRpyLZ60K4vTdbBsq555da7DwaaJem1BI0Uru47jA91ld5xICa6aR W1wHg14Ek5ZvQVCxVsQPxHTTcJq4qfyflaPg1AOSnLuvvDjBB4EuG0vBr5YR00yS tqidaIOoLClNAbQwufOidcOt8mYxvcmGLwr/PVIj71sj5XA2IsCywpEz/Vspe8xq 7Rx6Wqtb6z2bhx2RtmltahubugbDWyozhPEeIBCxpz5W+qfwCP7qMa5XEJiPD7jT oAowVaGD8AhYeT056AxgSfPJ717vBEB/Y0ZTqTOUhntGNcQNOVofeIOqlyS+rE8= =wpr9 -----END PGP SIGNATURE----- --QTprm0S8XgL7H0Dt--