[Samba] Status of Windows Search Protocol support in Samba?

[Noel Power]

On 21/04/2020 13:14, Mark Rousell via samba wrote:
> On 21/04/2020 12:38, Noel Power via samba wrote:
>> (resending, apologies if you got it already but I got a rejection message)
> This one got through on the Samba list.
>
> Thank you for your helpful reply.
>
>> yep, WSP server that translates protocol to tracker sparql queries is
>> working (with caveats [1])
>>
>> The code would need some effort to get it in shape, as you might imagine
>> there has been quite a bit of bitrot especially of late as recent dce
>> rework broke it (although I have a WIP version working against current
>> master (even more hacky than usual)
>>
>> I've also started to look at elastic search as a backend, and am going
>> to talk about that a little at sambaxp. Probably that talk would maybe
>> explain more (and in more detail) about some of these questions. I
>> intend to talk about state of the WSP work, revisit again and explain
>> how it works, what works, what doesn't,  what is provided, talk a bit
>> about experience of experimenting with elasticsearch how that affect
>> what needs to be done with the current implementation etc. (or something
>> like that :-))
>>
>>
>> Noel
>>
>> [1]
>>
>> WSP is complex, generic and very windows centric, there is a large
>> impedance  mismatch between the features that WSP seems to be able to
>> provide and query for and what say is available from tracker. (mileage
>> may vary with other indexers). The WSP support that I have worked on has
>> concentrated mainly on supporting the subset of queries that are emitted
>> when using the search UI ribbon in windows explorer. Additionally there
>> is a simple WSP samba search client that allows simple queries to
>> constructed to be targeted at any WSP server.
> Good idea, I think, about focussing on likely core searches from the
> Windows search UI (at least to begin with).
>
> I think that Elasticsearch vs. Tracker (or Baloo, or Recoll, or others)
> is largely a use case suitability issue. If one is querying a file
> server or a NAS then Elasticsearch is probably an ideal server-side
> indexing solution. On the other hand, if one is querying a desktop box
> (which is still a valid use case for WSP) then it would make more sense
> to query into whatever the user is already running (e.g. Tracker on
> Gnome, Baloo on KDE, Recoll on anything, Nepomuk on old KDE, and so on).
> However, I appreciate that this is all easier said than done.
>
> May I ask, is the index/search integration modular? What I mean is:
> Would it be possible/feasible to create a plugin structure that allowed
> third parties to create a plugin for an arbitrary indexing/search tool?
yes and no, there is an initial separation layer built into the server
implementation, currently only one concrete implementation
(tracker/sparql). Part of the rational to try use elasticsearch was to
really see if the separation layer is workable/suitable and to more
clearly identify parts of the code that could be shared for use by other
'backends'
> (And yes, I realise that creating a plugin infrastructure is even more
> work than integrating directly with Elasticsearch, Tracker, etc., so I'm
> just asking how things are. :-) ).
>
so currently I am not looking at a plugin infrastructure, I think it is
a bit early to nail api(s) in stone. I think when the code has
stabilised and there is more than one real concrete backend implemented
it might be a more suitable time to think about a plugin infrastructure.
As you say it's alot of work to get a plugin framework nailed down
(api(s) etc.) and currently this is just a hobby project for me

Noel