[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [smila-dev] search record: group by vs. faceting

Ok, ok. I'll do it  by seemingly popular request ;)

..after I have finished impl.ing the smila syntax filter, which  do currently.

Thomas Menzel @ brox IT-Solutions GmbH


-----Original Message-----
From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Igor Novakovic
Sent: Dienstag, 17. Januar 2012 11:17
To: Smila project developer mailing list
Subject: Re: [smila-dev] search record: group by vs. faceting

+1

Cheers
Igor

-----UrsprÃngliche Nachricht-----
Von: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] Im Auftrag von Thomas Menzel
Gesendet: Dienstag, 17. Januar 2012 07:29
An: Smila project developer mailing list
Betreff: Re: [smila-dev] search record: group by vs. faceting

hi folks,

quick question: since the current group by will become the future facetby i was wondering if we should make this simple rename now for 1.0 considering that this is sort of a breaking API change. for 3.5 we would impl. then the new group by.


Thomas Menzel @ brox IT-Solutions GmbH
(sent from mobile device)

JÃrgen Schumacher <juergen.schumacher@xxxxxxxxxxxxx> wrote:


-----Original Message-----
From: smila-dev-bounces@xxxxxxxxxxx [mailto:smila-dev-bounces@xxxxxxxxxxx] On Behalf Of Thomas Menzel
Sent: Friday, January 13, 2012 10:54 AM
To: Smila project developer mailing list
Subject: Re: [smila-dev] search record: group by vs. faceting

Hi,

>> drive this even further. The question is: do we want to spec it (filtering) in that detail as a general convention or shall we leave this to impl. of integrated search technologies?
> No I donât think we should specify too much. It would be just guessing. So rather: Keep it simple, let's focus on what we (you ;-) need today. If there is some really fancy feature next year that doesn't fit it, we can extend the specification then.

> I didnât pose my question here properly me thinks.

Or I didn't understand correctly (:

> Solr supports already now diff. kinds of faceting and hence the solr 
> impl. will spec this accordingly on its impl. page. In contrast to 
> that, we have the more generic convention that all impls should/could 
> adhere to. So the question was here: shall we drive the generic 
> convention to support all solr capabilities or shall we keep this more 
> simple than what can be done and spec'ed with solr? I think we shpuld keep the general spec fairly simple and to the most common use cases, in this case I would keep the generic faceting config limited to just the common enum case and the range stuff just on the solr side. Later we can generalize this too if we feel like it.

Yes, that's fine. The "general specification" should be simple and it should be possible to add additional elements easily. And the Solr integration could be seen as a first example of what could be added to the basic specification. Of course, other integrators should be encouraged to reuse the Solr extensions (if possible) instead of inventing the wheel again. I think we are on the same track here (:

>> I just think that JSON is more convenient for describing examples to human readers.
>... if u are used to it. ATM I still read XML more fluent than JSON ;)
Ok, so it's a matter of taste (: I'm sure we'll be able to understand each other regardless of the serialization (:

Cheers,
JÃrgen.
_______________________________________________
smila-dev mailing list
smila-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/smila-dev
_______________________________________________
smila-dev mailing list
smila-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/smila-dev
_______________________________________________
smila-dev mailing list
smila-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/smila-dev


http://www.Taglocity.com Tags: smila