Hi *,
popular OData provider called "ReflectionProvider" really simplifies building cutom data sources. The deal is that custom data source (any non-SQL, to begin with) exposes its object model (e.g. some POCOs), and then declares that it supports IQueryable<Foo>, IQueryable<Bar> and so on. ReflectionProviderdoes a lot (though, not all of) heavy-lifting, like building metadata, translating the wire OData protocol into Linq, and more. The custom data source, in its turn, undertakes to implement those IQueryables: give me the Linq query, and I will find those Foos and Bars (by talking to backend store, not necessary SQL; for example,to AD).
There is one weak point there, though. Namely, POCOs should declare their navigation properties as IEnumerable<T>. That means that processing of any query with conditions on the navigation side (e.g.~groups('groupname')/Members?$filter=JobTitle eq 'someJobTitle' is done by ReflectionProvider itself - it will ask for all members of the group, and then it will in-memory scan the whole list, on criteria like JobTitle. There is no way the custom data source can help (e.g. getting members by criteria, which might reduce the number of matching ones by several orders of magnitude).
I suggest that WCF Data Services consider support of reflection on IQueryable<T> navigational properties, instead of IEnumerable<T>. Data sources which are not very smart can still return .AsQueryable, but smart ones can really do their job.