drizzled::algorithm::
is my vote.
Monty Taylor wrote:
BIKESHED
I'm sorry to be an ass... but this conversation, while completely
important in general, has NOTHING to do with the thing Joe needs to
know... which is what should we name the namespace into which we place
md5 and crc32 functions inside of drizzle.
The libhashkit thing is a much more involved longer-term project that
there are still several things such as what brian is talking about that
need to be figured out.
Jay Pipes wrote:
I thought that is precisely what you were already doing with the
proposed libhashkit?
/me is confused.
-jay
Brian Aker wrote:
Hi!
I believe that the number of libraries that have to be
installed/compiled to make Drizzle compile needs to be kept small.
Protobuf is bad enough, but we shouldn't increase them.
CVS had this nice feature where you could chain trees together in
order to share files. I wish we had a feature like that in BZR.
I am not sure if the answer is we copy in new versions like we do
today and come up with a snazzy way of doing that, or if we somehow
find a way to link BZR. Creating more downloads though? That is a pain
and just creates more issuers for developers.
Cheers,
-Brian
On Jan 5, 2010, at 1:38 PM, Jay Pipes wrote:
1) Should these files (particularly the headers) be moved to a
shared, installable, dependency library project? If so, I would
assume it would be called pandora-something and be shared among
libmemcached, gearmand, drizzled, etc.
2) Regardless of whether the files are in a separate library or not,
should hashing functions be included in an xxx::algorithm:: namespace
or should there be a separate namespace just for hashing functions
(xxx::util:: for instance)?
My personal vote is for:
A separate library, named libpandora.
A namespace in said library called pandora::algorithm:: which
contains all algorithms (hashing, sorting, searching, etc).
Personally, I feel hashing functions are in the same category as sort
functions and search functions.
-jay
Monty Taylor wrote:
Ok. That's what Jay is talking about and the reason he advocates
drizzled::algorithm.
I am saying I don't have a problem with drizzled::algorithm for things
like sorting and searching, since that's the sort of things you'll find
in <algorithm> in the STL. But something that just computes a hash
doesn't belong lumped in with code that searches a container to me.
Jay Pipes wrote:
Understood, but we are talking about algorithms that are not
necessarily
restricted to just hashing. For instance, sorting and searching
algorithms. We are asking whether drizzled::algorithm:: is an
appropriate namespace for this work to go into? Or should it be
any of
the following?
pandora::algorithm::
pandora::util::
drizzled::util::
Something else?
-jay
Brian Aker wrote:
Hi!
On Jan 5, 2010, at 11:52 AM, Joe Daly wrote:
Currently what resides in this namespace is the crc32 implementation
used for md5 checksums.
The plan is to copy in libhashkit at some point (or use it if it is
locally installed). We are aways off from this though, but that is
the
eventual plan. I want to be able to re-use all of the
hash/distribution work in that library.
Cheers,
-Brian
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : drizzle-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : drizzle-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : drizzle-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
