[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tsp-devel] Black board variables size
From: |
Yves DUFRENNE |
Subject: |
Re: [Tsp-devel] Black board variables size |
Date: |
Mon, 19 Feb 2007 22:53:06 +0100 |
My simple opinion :
Put 256 to default size, and allow cmake to configure a new default if
necessary to be smaller or bigger.
And I think that compressing name is really too complex for that need.
Y++
2007/2/16, Eric Noulard <address@hidden>:
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
_______________________________________________
Tsp-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/tsp-devel
--
Un autre monde est possible,
il suffit juste qu'on s'y mette tous !