LCDproc development and user support list

Text archives Help

[Lcdproc] orphan drivers

Chronological Thread 
  • From: reenoo AT (Rene Wagner)
  • Subject: [Lcdproc] orphan drivers
  • Date: Wed Jul 30 19:17:02 2003

On Wed, 2003-07-30 at 13:05, Luis.F.Correia wrote:
> The most things programmers ask when writing new clients is this API.
> Normally the default response is: 'read the whatever.c source code
> for a practical example'. This scares off most programmers, me included.

We are not talking about changing the client _protocol_.
And the protocol is well defined by netstuff.txt.
You may argue about the name of that file and whether it does the job
but it's there.
Joris has recently written docs/lcdproc-dev/language.docbook which
should cover the current state of 0.5.
Certainly, the file name is wrong once again because the correct term
is protocol.

> The stable API (0.4.x) should be published.
> Of course, practical example code must be provided.

I assume you are still refering to the protocol...
There is some perl example code in the clients directory.

> The unstable/development API (0.5.x) should also be published.
> Side-notes must be taken, to warn the programmer of potential API changes.

There should be no need for a warning. The client protocol should always
be backwards compatible. Otherwise a major version change would seem
neccessary to me.

> Then, in this mailing list, there is a lot of discussion over very tiny
> details, that slows down development to almost a complete halt.

That's wrong.
The things we are discussing at the moment (driver API) are far from
being tiny details.

And speaking of myself only... I just don't have much time for coding
ATM :(

> All we need to look for is the date for the stable release...
> (from the download page) LCDproc v0.4.3 Released May 30, 2002

There are nightly tarballs for 0.4.4-CVS, you can get the code from
CVS, and the stable-0-4-4 branch is pretty stable.

You may mark this as being inconvenient, sure, not perfect for the
presentation of the project to the outside world, too.

> I know i'm now helping. I'm even confusing some.
> PLEASE! agree to something and release.

We are currently discussing design issues for 0.5.
0.5 is far from being released at anytime soon.

There are two major things that prevents me from saying OK to a 0.4.4
release. I hope to get to that this weekend, but I've said that many
times before and... :(

> Then support new stuff in new releases.

Sure... but a release is something I won't agree to when I know
about certain issues and haven't fixed yet. I'm not talking feature
enhancements here but serious bugs.

> Keep changing the API as many times you want, BUT for each API a release
> must exist.

Once again... The client protocol should always remain backwards
Yet, if you want to write a new driver you have to look through
the source code anyway and won't mind changes to the driver API that

> p.s. the lcdproc package for Bering uClibc is packaged and maintained by me.

Does 0.5 work on a uClibc based system?

Thanks for the feedback,


Archive powered by MHonArc 2.6.18.

Top of page