I also want to add that you could add MD5 and SHA-1, but I'd check on us laws... I think these are ok, however other encryption/decryption code is not.
They are part of the std sun java libraries ... Sent from a remote device. Please excuse any typos... Mike Segel On Mar 16, 2013, at 7:18 AM, Michel Segel <[email protected]> wrote: > Isn't that what you get through add on frameworks like TSDB and Kiji ? Maybe > not on the client side, but frameworks that extend HBase... > > Sent from a remote device. Please excuse any typos... > > Mike Segel > > On Mar 16, 2013, at 12:45 AM, lars hofhansl <[email protected]> wrote: > >> I think generally we should keep HBase a byte[] based key value store. >> What we should add to HBase are tools that would allow client side apps (or >> libraries) to built functionality on top of plain HBase. >> >> Serialization that maintains a correct semantic sort order is important as a >> building block, so is code that can build up correctly serialized and >> sortable compound keys, as well as hashing algorithms. >> >> Where I would draw the line is adding types to HBase itself. As long as one >> can write a client, or Filters, or Coprocessors with the tools provided by >> HBase we're good. Higher level functionality can then be built of on top of >> HBase. >> >> >> For example, maybe we need to add better access API to the HBase WAL in >> order to have an external library implement idempotent transactions (which >> can be used to implement 2ndary indexes). >> Maybe some other primitives have to be exposed in order to allow an external >> library to implement full transactions. >> Or we might need a statistics framework (such as the one that Jesse is >> working on). >> >> These are all building blocks that do not presume specific access patterns >> or clients, but can be used to implement them. >> >> >> As usual, just my $0.02. >> >> -- Lars >> >> >> >> ________________________________ >> From: Nick Dimiduk <[email protected]> >> To: [email protected] >> Sent: Friday, March 15, 2013 10:57 AM >> Subject: Re: HBase type support >> >> I'm talking about MD5, SHA1, etc. It's something explicitly mentioned >> in HBASE-7221. >> >> On Fri, Mar 15, 2013 at 10:55 AM, James Taylor <[email protected]>wrote: >> >>> Hi Nick, >>> What do you mean by "hashing algorithms"? >>> Thanks, >>> James >>> >>> >>> On 03/15/2013 10:11 AM, Nick Dimiduk wrote: >>> >>>> Hi David, >>>> >>>> Native support for a handful of hashing algorithms has also been >>>> discussed. >>>> Do you think these should be supported directly, as opposed to using a >>>> fixed-length String or fixed-length byte[]? >>>> >>>> Thanks, >>>> Nick >>>> >>>> On Thu, Mar 14, 2013 at 9:51 AM, David Koch <[email protected]> >>>> wrote: >>>> >>>> Hi Nick, >>>>> >>>>> As an HBase user I would welcome this addition. In addition to the >>>>> proposed >>>>> list of datatypes A UUID/GUID type would also be nice to have. >>>>> >>>>> Regards, >>>>> >>>>> /David >>>>> >>>>> >>>>> On Wed, Mar 13, 2013 at 5:42 PM, Nick Dimiduk <[email protected]> >>>>> wrote: >>>>> >>>>> Hi all, >>>>>> >>>>>> I'd like to draw your attention to HBASE-8089. The desire is to add type >>>>>> support to HBase. There are two primary objectives: make the lives of >>>>>> developers building on HBase easier, and facilitate better tools on top >>>>>> >>>>> of >>>>> >>>>>> HBase. Please chime in with any feature suggestions you think we've >>>>>> >>>>> missed >>>>> >>>>>> in initial conversations. >>>>>> >>>>>> Thanks, >>>>>> -n >>>>>> >>>>>> [0]: >>>>>> https://issues.apache.org/**jira/browse/HBASE-8089<https://issues.apache.org/jira/browse/HBASE-8089> >>>>>> >>>>>> >
