[lcdproc] (driver)IDs (was: dealing with multiple instances with .so)

[Andre Breiler]

On Thu, 29 Mar 2001, Matt wrote:

> Andre Breiler mentioned the following:
> 
> | NOTE: in this mail is screen the physical device!
> 
> | On Thu, 29 Mar 2001, Matt wrote:
> | 
> | > each screen from the libmtxorb.so, it will return an id for that instance,
> | > probably just number from 0 or 1 upwards. Therefore we can give each and
> | 
> | This is something what the lcdd have to count because the libfuntion
> | itself doesn't know the numer of instances (the only way is the open
> | counter of the lib).
> 
> No, each driver can maintain it's own count internally, this isn't a
> problem. As each multiple instance of any library will be the same
> instance, a simple static counter would suffice. Something more elaborate
> might be needed if the situation arose, but the idea is the same.

Ok, I agree.
Maybe we should redefine the question: Where do we need this ID ?
So we can figure out in which area (time/environment) the ID should be
unique.

> | > every screen its own id by just combining each driver name with the
> | > instance id, we have mtxorb0, mtxorb1, cfontz0, etc.
> | > 
> | > Far more simple IMHO we don't need quite as many config options now.
> | 
> | Hmm, so if I connect as client can I say I like the screen X and I get
> | every time the same screen ?
> | I don't think because it depends on the way how we parse the
> | config and load/init the drivers.
> 
> I thought that the server would supply a more verbose list of displays
> available to each client, much more than it does currently. Such that it
> might say: "mtxorb0 - Matrix Orbital display, 20x4, connected to
> /dev/ttyS1", etc. Such that if a client always wants to connect to the
> display hooked on /dev/ttyS1, you can pattern match to get the correct id,
> in this case mtxorb0.

Ok, this brings up another problem. What happens on a server reload if the
ID changes ?
In my approach it changes if I redefine the env (e.g. other device) and in
yours if I add a new driver and it's initialized bevor the current one. 

> | The idea not to use a server supplied ID was that we can use in all parts
> | of the system (also for distributed drivers).
> | With you approch I have to calculate a different ID (which is
> | also unique in the distributed case) in a wrapper for distributed drivers.
> | Is also not possible to guess the ID if you don't cant remeber ther order
> | of the config sections ...
> 
> The one problem with not auto-generating ids, is that you make the client
> dependent on the server config, the two should not have to be
> co-configured by the same person.

Ok, point taken. So we are talking now about the generation of a unique ID
? If so should we kick off a new thread ?

Tschau ANdre'
-- 
Andre' Breiler                       |   Tel: +44 1737 839532
BBC Internet Services                | Email: andre.breiler@rd.bbc.co.uk 
Kingswood Warren,Tadworth,Surrey,UK  |   URL: http://support.bbc.co.uk/
Mail me.  Don't phone if possible. And use a Subject line.



-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net