Welocme to the world of re-linq, Jordi!
An implementation of this interface is used to turn the .NET expression tree into something more managable, the main task of re-linq. You normally only interact with the result, the QueryModel and transform the information contained in there into your SQL or other format.
It implements the typical steps required for turning an expression tree into a QueryModel. It also has a factory method which does the default composition. You can also instantiate your own composition if you have special requirements not covered by by DefaultQueryParser.
>What could I do implementing this interface?
You mean, beyond what re-linq already does in the default implementation? Hmm...I'm not sure this has ever come up, NHibernate and EntityFramework just customize the composition, I believe. But you could basically do any sort of pre-processing of the expression tree (not recommended since it defeats the primary purpose of re-linq, namely helping you in not having to work with the original expression tree as generated by the compiler) and post-processing of the QueryModel (if the other extensionpoints do not suffice) before the query is executed by the QueryableBase. As I said, normally, you shouldn't have to implement it yourself.
>Which's the difference between ExpressionTreeParser?
IQueryParser is a potential extension point and a facade between the higher-level stuff and the parsing logic. ExpressionTreeParser does the actual work (or delegates it to extension points, etc). It's also not extensible via interitence or mockable, unlike IQueryParser.
On the CodePlex site (http://relinq.codeplex.com/
) we also have several resources linked (blog post, a primer, Fabian's blog posts) to help you get deeper into working with re-linq.
Best regards, Michael