Re: Data models and filtering (was: Re: Contacts API draft)

On Fri, Jan 18, 2013 at 11:21 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Jan 7, 2013 12:54 AM, "Kis, Zoltan" <zoltan.kis@intel.com> wrote:
>> On Fri, Jan 4, 2013 at 12:31 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
> I think there are two main issues that we are discussing in this thread:
>
> * What type of filtering to allow when querying the database.
> * How to build a synchronization mechanism to allow an application to
> store the data locally such that it can perform queries which aren't
> supported by the API.
>
> I think the second point we'll have an easier time to get to agreement
> on since I think we agree on the capability set there. So let's attack
> the first point separately.

Yes, we could reach agreement on sync pretty easily.

About filtering, IMO it is needed for 2 quite different scenarios:
- targeted applications which build their (pretty much known and
hard-coded) data models, which are performance-critical;
- search apps, which need much more indexes, but are not that much
performance-critical.

However, if you keep your data in one place (which may be desirable,
maybe not, depending on the use case), then you anyway need to create
indexes for generic searches. Once you have the indexes anyway, is it
a problem using them for supporting a generic filtering API? Or if
not, how do you solve desktop search? With separate solutions, it's
not going to save space anyway. Does it save complexity, or does it
distribute complexity better? By how much? Is it worth?
Are you afraid of compromising insert performance? But that is not an
issue for most data in a device, once we have a sync API...

I have to agree with you though that if I have to choose between
generic filters with bad performance and narrow API's with good
performance, I'd choose the good performance in a product. But I don't
see that we have that battle.

Between the SMS filter in Eduardo's proposal and the generic filter in
my Messaging API the difference is mainly only how it is written down.
Both need a lot of properties (and not all of them). Eduardo specified
them in a dictionary, I document in each property description if it
needs to be filterable. The important difference is that I use a
generic API and narrow it down from the spec, rather than narrowing
down the API. I think this leaves more options for the future without
the need of API break, while making possible to implement specific
filters now. In both cases, you'd need to write comparable amount of
indexes.

To keep it short and contained, let's agree on these first.
I will address the rest in a next mail.

Best regards,
Zoltan

Received on Friday, 18 January 2013 12:39:45 UTC