[DISCUSS] Feed Item Query Language

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Feed Item Query Language

Jan Bernhardt
Hi Syncopers,

I'm currently working on updating our CXF migration website [1]. While I was starting documentation some month ago, I discovered a nice feature CXF offers, to make more standard like search queries, that can easily be applied to different persistent layers. It is called "Feed Item Query Language"(FIQL). Take a look at [2] for more detailed information.

We are currently using our own custom *Cond classes to POST search requests. According to RESTful best practices it would be nicer, to send these kind of search queries via GET operation. With FIQL we could easily achieve this behavior.

So my proposal would be to create a new JIRA ticket (for 1.3.0 ?) to switch our current implementation to support and use FIQL search queries in the feature, and also update our Roadmap accordingly.

WDYT?

Best regards.
Jan

[1] https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#RESTAPIupgrade-ConfigurationService
[2] http://cxf.apache.org/docs/jax-rs-search.html
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Feed Item Query Language

ilgrosso
Administrator
On 30/01/2013 11:27, Jan Bernhardt wrote:
> Hi Syncopers,
>
> I'm currently working on updating our CXF migration website [1]. While I was starting documentation some month ago, I discovered a nice feature CXF offers, to make more standard like search queries, that can easily be applied to different persistent layers. It is called "Feed Item Query Language"(FIQL). Take a look at [2] for more detailed information.
>
> We are currently using our own custom *Cond classes to POST search requests. According to RESTful best practices it would be nicer, to send these kind of search queries via GET operation. With FIQL we could easily achieve this behavior.
>
> So my proposal would be to create a new JIRA ticket (for 1.3.0 ?) to switch our current implementation to support and use FIQL search queries in the feature, and also update our Roadmap accordingly.
>
> WDYT?

+1 - if there is a standard (AFAIU is [3]) I don't see any reason to
stuck with our custom way.
A mandatory statement for this change is, of course, to not reduce the
space of possible conditions that can be currently searched for.

I also agree with targeting this change to 1.3.0.

Regards.

> [1] https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#RESTAPIupgrade-ConfigurationService
> [2] http://cxf.apache.org/docs/jax-rs-search.html
[3] http://tools.ietf.org/html/draft-nottingham-atompub-fiql-00

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/


Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Feed Item Query Language

Sergey Beryozkin
Hi
On 30/01/13 10:43, Francesco Chicchiriccò wrote:

> On 30/01/2013 11:27, Jan Bernhardt wrote:
>> Hi Syncopers,
>>
>> I'm currently working on updating our CXF migration website [1]. While
>> I was starting documentation some month ago, I discovered a nice
>> feature CXF offers, to make more standard like search queries, that
>> can easily be applied to different persistent layers. It is called
>> "Feed Item Query Language"(FIQL). Take a look at [2] for more detailed
>> information.
>>
>> We are currently using our own custom *Cond classes to POST search
>> requests. According to RESTful best practices it would be nicer, to
>> send these kind of search queries via GET operation. With FIQL we
>> could easily achieve this behavior.
>>
>> So my proposal would be to create a new JIRA ticket (for 1.3.0 ?) to
>> switch our current implementation to support and use FIQL search
>> queries in the feature, and also update our Roadmap accordingly.
>>
>> WDYT?
>
> +1 - if there is a standard (AFAIU is [3]) I don't see any reason to
> stuck with our custom way.
> A mandatory statement for this change is, of course, to not reduce the
> space of possible conditions that can be currently searched for.
>

IMHO using FIQL can definitely be interesting: it can expand the space
indeed, in a way which is not always easy to do with simple queries, so
+1 to getting FIQL supported;
That said, in addition, I'd also consider offering a simple/typical
name/value query interface to let users who are most comfortable with
using plain name/value pairs to use them as usual - but also offer a
more enhanced FIQL-powered interface - I guess this flexibility can be
supported without too much extra complexity, with a single Search
service only...

Thanks, Sergey

Reply | Threaded
Open this post in threaded view
|

RE: [DISCUSS] Feed Item Query Language

Jan Bernhardt
Jira issue created: https://issues.apache.org/jira/browse/SYNCOPE-300

What a magic number ;-)

Best regards.
Jan


> -----Original Message-----
> From: Sergey Beryozkin [mailto:[hidden email]]
> Sent: Mittwoch, 30. Januar 2013 11:50
> To: [hidden email]
> Subject: Re: [DISCUSS] Feed Item Query Language
>
> Hi
> On 30/01/13 10:43, Francesco Chicchiriccò wrote:
> > On 30/01/2013 11:27, Jan Bernhardt wrote:
> >> Hi Syncopers,
> >>
> >> I'm currently working on updating our CXF migration website [1].
> >> While I was starting documentation some month ago, I discovered a
> >> nice feature CXF offers, to make more standard like search queries,
> >> that can easily be applied to different persistent layers. It is
> >> called "Feed Item Query Language"(FIQL). Take a look at [2] for more
> >> detailed information.
> >>
> >> We are currently using our own custom *Cond classes to POST search
> >> requests. According to RESTful best practices it would be nicer, to
> >> send these kind of search queries via GET operation. With FIQL we
> >> could easily achieve this behavior.
> >>
> >> So my proposal would be to create a new JIRA ticket (for 1.3.0 ?) to
> >> switch our current implementation to support and use FIQL search
> >> queries in the feature, and also update our Roadmap accordingly.
> >>
> >> WDYT?
> >
> > +1 - if there is a standard (AFAIU is [3]) I don't see any reason to
> > stuck with our custom way.
> > A mandatory statement for this change is, of course, to not reduce the
> > space of possible conditions that can be currently searched for.
> >
>
> IMHO using FIQL can definitely be interesting: it can expand the space
> indeed, in a way which is not always easy to do with simple queries, so
> +1 to getting FIQL supported;
> That said, in addition, I'd also consider offering a simple/typical name/value
> query interface to let users who are most comfortable with using plain
> name/value pairs to use them as usual - but also offer a more enhanced
> FIQL-powered interface - I guess this flexibility can be supported without too
> much extra complexity, with a single Search service only...
>
> Thanks, Sergey
>
> > I also agree with targeting this change to 1.3.0.
> >
> > Regards.
> >
> >> [1]
> >>
> https://cwiki.apache.org/confluence/display/SYNCOPE/REST+API+upgrade#
> >> RESTAPIupgrade-ConfigurationService
> >>
> >> [2] http://cxf.apache.org/docs/jax-rs-search.html
> > [3] http://tools.ietf.org/html/draft-nottingham-atompub-fiql-00
> >