Re: [Tsp-devel] Black board variables size

[Yves DUFRENNE]

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 !