Re: [Lcdproc] Elektrify LCDproc

--===============3120077348908043980==
Content-Type: multipart/signed; boundary="nextPart1794407.uQ38zGjkEm";
	micalg="pgp-sha256"; protocol="application/pgp-signature"


--nextPart1794407.uQ38zGjkEm
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Hi lcdproc-list,

I'll cover multiple answers in a single mail.

20. March 2017, 13:59:23 Philip Prindeville wrote:
> From my perspective, most of the environments where I use or would ex=
pect to
> use LCDproc, glib2 is already present and supports .INI file parsing.=


We do not propose to replace an INI parser but to abstract configuratio=
n=20
access.

> Maybe something less ambitious is more assured a success?

We also considered to only replace shared/configfile.c.

But as described in the news item in LCDproc a lot of second-stage=20
configuration parsing is spread over in many modules. Thomas looked at =
it and=20
said it would be okay to clean this up, too.

> > - You can use Shell, Python, or Lua to write small scripts that are=

> > executed>=20
> >  on configuration access.
>=20
> No Perl bindings?

Unfortunately, currenlty not. We would love to have Perl bindings!
Perl bindings are currently the most requested ones.
Contributions are very welcomed.



William Ferrell wrote:
> With all due respect, this reeks of a sales pitch to me. I agree with=

> Philip that something like glib2's INI support is more appropriate fo=
r this
> purpose. There are plenty of other standard formats for configuration=
 files
> with adequate library support, including YAML, XML and JSON.

Yes, but with all of them you are tied to a specific format. In Elektra=
 the=20
user has the choice between these formats.

> "Brand-name-ifying" LCDproc by tying it to yet another format just se=
ems
> we're being used as another notch on the bedpost by the format's vend=
or. I
> apologize in advance if I'm mischaracterizing this, but it's certainl=
y how
> it appears to me so far.

Elektra certainly does not tie to you any format, instead it gives you =
the=20
freedom to choose.

> In terms of poor and/or conflicting documentation, I wish someone had=

> brought it up on-list (or to my attention here or via Github). Recent=

> updates to the project have taken some steps to improve documentation=
 and
> more can be done as well to rectify this without relying on a third-p=
arty
> vendor to document the configuration details (and then maintain and h=
ost it
> on a separate site).

Nothing will be hosted on a different site. The specification and every=
thing=20
will of course be only in your repo. The configuration snippets service=
=20
mentioned in the news is free software, too. If you want, you can host =
it=20
yourself.

> I'm long overdue to redesign the LCDproc website [...]
> I'll devote some time in the next two weeks to get this done.

Sounds great!

> The fact that my reply (above) was bounced by the philipp_subx@redfis=
h-
> solutions.com mailbox as spam

I do not know anything about him or why there are bounces from his emai=
l=20
address.

> and marked for moderation awaiting approval
> on the Elektra mailing list doesn't fill me with confidence either.

Sorry, our mailinglist is not hosted by us (It is still on sourceforge.=
 It is=20
basically only used for news, all discussions were moved to github.). Y=
ou need=20
to subscribe first before you can post something there.

> glib2 was just an example. If size is a concern, there are INI parser=

> libraries that are much smaller than libelektra or glib2.
> https://github.com/benhoyt/inih comes to mind; it's 305 lines in two =
files
> (.h and .c). Low-memory embedded systems are specifically mentioned i=
n its
> README as a target.

One of our ini parser is based on inih. I would not recommend to use in=
ih=20
directly, we had quite some problems with it.

The problem you have in your source is not only the ini parser, but mai=
nly=20
second-stage parsing.

> I don't have any objection at all to configuration examples being sha=
red
> anywhere. I had the impression there was a move being made here to mo=
ve
> official documentation and examples away from the project repo and/or=

> website.

It is the goal of Elektra that projects maintain specifications themsel=
ves.
It wouldn't scale otherwise.

> I don't really see the need for this. LCDproc itself can warn about
> nonsensical configurations, or even abort when they result in a non-v=
iable
> situation. This isn't a system tool like sudo where a typo in the con=
fig
> file can lock even the admins out of the system. The worst outcome fr=
om a
> misconfigured LCDproc is that it won't start, or won't display things=

> properly if it does start.

Or that it starts, and fails due to an error anytime later when the mod=
ule=20
first requests the config. These are lots of latent errors you normally=
 would=20
want to avoid.

(sales pitch) With Elektra also your clients could write to the configu=
ration=20
file.

> We can certainly formalize the configuration specification more than =
it is
> now, but I still feel like this particular approach is the equivalent=
 of
> swatting a fly with a shotgun.

The specification is modular, you can choose which parts of it you want=
. At=20
minimum you could only specify the types and defaults. Our idea is to s=
pecify=20
everything you currently have specified. (Maybe with bug fixes)

best regards,

=2D-=20
Markus Raab            https://www.libelektra.org
Technische Universit=C3=A4t Wien       [email protected]
Institut f=C3=BCr Computersprachen           Phone: (+431) 58801/185185=

Argentinierstr. 8, 1040 Wien, Austria     FAX: (+431) 58801/18598

DVR 0005886
--nextPart1794407.uQ38zGjkEm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUAWNI1bUyVgPULLw3cAQgaohAAt64Ce9SlqarJaKdcnrvZuSqj7WZ4GBkQ
DxAb+ahiRsAVm7YgjYDiDJOsCh5E4ZkzocVJjiX/UZW3NJ/eSPYNyG/HIUuZ+i2J
Ti2unJ3jNmSvIFxnYeHuYExUz53yrl/PD5ai730Mq4Pian47RLrdyExuGc5bOnPN
ATKnk/zzDFzitJRTkCyC4vifysDBve8gL+tdMDhmBSvuN6FCiq1wZGWj8/vrY+lH
Wwvd8jkkqtGOTE+MraDnMH2lTm3PwoNjBmXknB4pgw5QP9a3SyM/NYhCNAg+xWMp
F3J/0wwocgMbgZeWWhjLn6PnTvivda//anmLzDdxtOGPZY3cxNysfnFtJ/B3D++j
K+Dpr8SwX0B2AvccwE9s6lbyYgIfnaT53rfkhFj5UA7EIivpZKDyRqbokaGPD3wA
mlz9LUMWo5yxlYmh27FTwASDk6V26iXnyu6mVq/r71zz1YYzI7yCBo4UpRlVPgHQ
BC7RcaVHc93JkC8iOl65MVREVWzQV0Bb5IdkA+Ac2Iy95CJNvjbMxFWXD7BeF4gz
R7zggIHe3G5cEXFeOBlYDsY5ERoPf4xKoufZh5oJYIDvHH/rR1MKbuuLxoktrLRV
ZPXyZfwmoWpV9mSo2zxKsN+MfAHoVkU31TaVUSCmShXa13ZscWsz8FbnuWUdmC0Q
Vy240mFnRWw=
=Y45a
-----END PGP SIGNATURE-----

--nextPart1794407.uQ38zGjkEm--



--===============3120077348908043980==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--===============3120077348908043980==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Registry-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/registry-list

--===============3120077348908043980==--