[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tsp-devel] Black board variables size
From: |
Eric Noulard |
Subject: |
Re: [Tsp-devel] Black board variables size |
Date: |
Fri, 16 Feb 2007 19:47:37 +0100 |
2007/2/16, Frederik Deweerdt <address@hidden>:
Hi,
I'm running in some problems with a dynamically generated BB: the
variable names are too long. This could be solved by increasing the
value of bb_core.h:VARNAME_MAX_SIZE to something bigger than 150,
The VARNAME_MAX_SIZE was meant for this.
But I remember I had the exact same CONVERSE problem!!
I add to downsize VARNAME_MAX_SIZE from 1024 to 150 because
of the memory consumption incurred by those string
when creating "big" Blackboard.
I was stupid to put 1024 in the first place
Now I think I wasn't smarter to put 150 afterwards
(don't ask me why I chose 150).
This was before the current Blackboard code reach CVS at Savannah though.
but I'm afraid that I'll become incompatible with other BB versions.
Yes it will, you are right.
Any ideas?
1) fix your name manglling scheme in order to have smaller
names :))
2) Make the VARNAME_MAX_SIZE a new parameter of
struct S_BB and a parameter of bb_create and propagate
the change.
This will make the new BB incompatible with previous one
but new version may adapt itself to different sized VARNAME_MAX_SIZE.
3) [My Favourite]
For some kind of application you'll have to consider
S_BB_DATADESC::name
as a "key" with no particular human meaning, say name
may be "FGF5652KHDKDK" or SHA1 sum of the "real name".
(see bb_sha1.[ch] for the code)
then only add option to bb_tools/bb_core API
to hash the "realname" you give to them or better
write a bb_hashed API as a wrapper to bb_core just
as bb_simple do.
Then you can limit the size of your "name" since
they are "keys" and 150 character should be enough for
unique keys.
With this approach you should replace/wrap
you bb_subcribe/bb_publish calls into
bb_hashed_XXXXX calls.
And you loose one interesting bb_tools function "find"
bb_find won't wokr as expected.
If you really need to have HASH/KEY --> REALNAME
you'll have to create out of BB database for this.
3bis) Late thought - LossLess compress
Instead of one way has like (SHA-1 or MD5 or whatever)
use lossless compression algorithms
http://en.wikipedia.org/wiki/Data_compression
http://fr.wikipedia.org/wiki/Compression_de_donn%C3%A9es
This is an interesting problem because deep ALIAS published
data (alias-of-alias-of-alias etc...) would generate long names
too.
If ever you experiment with change which makes the new
bblib incompatible do not forget to update
bb_core.h:BB_VERSION_ID.
bb_tools and bb_lib may now check for mismatch if asked for
see bb_check_version API.
I would go for 3) or 3bis) with wrapper bb_compress_xxxx / bb_hash_xxx API
but we should check twice.
It may be worth an incompatibility if we are sure to get rid of this
problem for EVER [for which 3bis cannot help] :))
--
Erk