The title should read 'Riak will support Secondary Indices.' As an open source company, we strive for transparent engineering; this is intended as a preview of some upcoming functionality. We haven't set a release date yet.
Just want to properly set expectations.
That said, we appreciate the interest and attention. :)
The design of secondary indexes is much simpler, more tightly integrated, and more transparent than Riak Search. It will feel more like part of the same datastore, rather than something you have to deal with on the side.
This could make riak actually useful to the masses as a fine database! Certainly one of my biggest beefs with riak was the overly difficult interface it has and its lack of secondary indexes.
The choice of protocol buffers as the serialization format is also kind of weak imho. There are some really piss poor protobuf implementations that are slower than serializing to xml or json. The python version especially comes to mind.
Sorry, I'm going to make an assumption that by interface difficulty you mean it's ability to be queried (map reduce only + lucene {optional})? Also, nothing forces you to use protobuffs, you can tell riak what (via the content type of an http header) what your data is and get it back as such. I don't see that as a weakness.
I haven't seen anything announced on Basho's website either. The talk abstract describes the talk as being the "unveiling" of secondary indices so it does seem like July is the release date.
Just want to properly set expectations.
That said, we appreciate the interest and attention. :)