From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MLMkp-00066F-BN for garchives@archives.gentoo.org; Mon, 29 Jun 2009 19:43:03 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1681CE0583; Mon, 29 Jun 2009 19:43:02 +0000 (UTC) Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by pigeon.gentoo.org (Postfix) with ESMTP id 9D13DE0583; Mon, 29 Jun 2009 19:43:01 +0000 (UTC) Received: by fxm7 with SMTP id 7so265238fxm.34 for ; Mon, 29 Jun 2009 12:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer; bh=cN3WlUqb7iO1IRSKUAQ9zPscBpSlmJa0X4H4H5479r0=; b=eajhpcgnXWiQF6JCoO+3LKWcYB/q30hQFS3sDM51xticb+iOoYhnyIbWDT4mTq7lkv xa+wPNzALp3lrjDE4ZswGN9G3Jp/9Y5VAWaQTAJEawVax1mcdVR2E3Wsu86HHT1FspdV PXRSK6rljI+o6nvdVwYC4BDSAG7ACM8FkKp1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer; b=XH8WtUcA2Z6P+1eu0td9GjzZOcPk1QS22IJ3ysUul8kFl9fqhoP3FY3giQhwi+PFvi Y6G++bLt33wydQQcHfkpUginZ60MjnmKoUHgpRmvlKZe57ZvaPBJSXJg6XT6g/Iafb47 mVBsI1wKWswdOX2jicXprosyY/83xLQxLrUVc= Received: by 10.103.1.17 with SMTP id d17mr4316583mui.60.1246304580987; Mon, 29 Jun 2009 12:43:00 -0700 (PDT) Received: from ?192.168.127.16? (magdalene.ist.utl.pt [193.136.161.161]) by mx.google.com with ESMTPS id s10sm32556142muh.57.2009.06.29.12.43.00 (version=SSLv3 cipher=RC4-MD5); Mon, 29 Jun 2009 12:43:00 -0700 (PDT) Subject: [gentoo-dev] Re: [gentoo-soc] Re: Progress on Universal Select Tool From: =?ISO-8859-1?Q?S=E9rgio?= Almeida To: gentoo-soc@lists.gentoo.org Cc: Gentoo Dev In-Reply-To: <4A490FAC.6000105@hartwork.org> References: <1245163715.14589.515.camel@thedude> <1246301448.4316.68.camel@thedude> <4A490FAC.6000105@hartwork.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-uNpZOByhkKk2fDO//D0T" Date: Mon, 29 Jun 2009 20:42:58 +0100 Message-Id: <1246304578.4316.92.camel@thedude> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 X-Archives-Salt: 02e2df71-2a28-45f8-a55e-122a74b89637 X-Archives-Hash: 3d8628b92a0324e23b71bef0d4e689de --=-uNpZOByhkKk2fDO//D0T Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sebastian, > It seems to me that the original langauge is "static"/"descriptive" > while Python is not. Why not move to XML or JSON (former seems more > common with Gentoo) instead of Python? Think about how much easier it > is to pull information from metadata.xml than from .ebuild files - it's > the same difference in your case. I considered XML/JSON in this decision and did not even discussed it with my mentor. This is indeed not and abandoned idea as I explain below. >=20 > You know much better where you want to go with this than I do, but > please triple-check this move, as you cannot go back. >=20 I'm in no position to chose the path to take but for now python still seems the chosen "vehicle". Remember that using XML/JSON for modules would never need a re-write from uselect but would only be an extension to the module system. Let us see. In uselect everything are objects.=20 Module is a class Action is a class Module(s) have Action(s) Actions are interfaces to many kinds of actions, Sym, Path, Runnable Sym and Path actions have Link(s) Runnable actions have code and know how to execute it. Therefore the backend scenario (object space) is the same as the new suggested module syntax. Basically this decision is not adding a feature. It is abandoning the "uselect syntax" thus removing a feature. This will help during development as parsing is the task that has been more time consuming during uselect's development. With this uselect will have an open interface for extension to any markup language that comes in handy in module readability/programming. >=20 > Thanks for listening, >=20 >=20 >=20 > Sebastian >=20 I thank you. Will now add the markup language support to the to-do list, not to implement right away but to have in mind while expanding the API. Cheers, S=C3=A9rgio --=20 S=C3=A9rgio Almeida - mephx.x@gmail.com mephx @ freenode --=-uNpZOByhkKk2fDO//D0T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkpJGTwACgkQQXumuXcKj07+GACfb6hl+z0vTXlnDVwK8ZnhxkWv 2kIAn2R7lPbrQxpUpTyf5uXhTnyYzvKn =Qn43 -----END PGP SIGNATURE----- --=-uNpZOByhkKk2fDO//D0T--