samba - Apr 2020 - Status of Windows Search Protocol support in Samba?

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

Noel,

On 21/04/2020 13:40, Noel Power via samba wrote:
> 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.
Understood. That all makes sense.
> 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
Yup, there are many thing that could be useful but where there seems to
be little scope for monetising them. Transparent cross-device search
like this is something that people would tend to take for granted when
it works (as long the client UI is decent) but that they probably aren't
will to pay for.

Ideally, perhaps, this is something that an OS or NAS vendor might be
willing to pay for but, even there, there is little explicit demand for
this type of feature set. In large part I think this is because people
don't know what to ask for. And yet searching NAS contents from clients
is something that people do seem to desire.

Anyway, thank you for all the work you have put into this.

Even simply knowing what state things are at is extremely helpful from
my point of view.


-- 
Mark Rousell

Am 4/21/20 um 3:42 PM schrieb Mark Rousell via samba:
> Ideally, perhaps, this is something that an OS or NAS vendor might be
> willing to pay for but, even there, there is little explicit demand for
> this type of feature set. In large part I think this is because people
> don't know what to ask for. And yet searching NAS contents from clients
> is something that people do seem to desire.
get a Mac and use Samba's Spotlight support. :)

Or use mdscli from a Linux client if you prefer. :)))

-slow

-- 
Ralph Boehme, Samba Team                https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20200421/84bcdb17/signature.sig>