Re: [Tsp-devel] Black board variables size

[Eric Noulard]

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