[XESAM] Search API Update Proposals

[Evgeny Egorochkin]

On Thursday 02 August 2007 21:31:35 Mikkel Kamstrup Erlandsen wrote:
> I've been collecting comments on the Xesam spec lately, and I think we have
> enough now to do an update round of the spec proposal.
>
> Proposed changes can be found here:
> http://wiki.freedesktop.org/wiki/XesamSearchUpdates

> 2. Type Attribute in Query Language

I agree with Jamie that usually people will just enumerate categories in which 
to search, without any complex criterias.

My concern with <query category="xesam:Audio"> is that it may not play nicely 
with services, which may use a different class structure/trees. It would be 
nice to also have a more generic way to specify categories, by treating them 
as regular fields.

One of possible ways here is to treat query attrs as a shortcut, while letting 
implementations also support(at their discretion) the more generic approach.



Also, if no category is specified, there must be some defaults, however I feel 
they are hard to establish:

One user might by default want to search files only. Other user might prefer 
to search both files and archives. Typical case is extensive musical library 
in archives, stored this way for easy P2P sharing, while user uses plug-ins 
to listen to music directly in archives.

Defaults for categories should be probably user-configurable and/or 
implementation-specific. Client apps are best off stating categories 
explicitly.

> 4. Problems With Hit Data

We have the following potential solutions:

	aas] works except for ambiguity in strings

	aav] have to use a workaround, like treating one of unused datatypes as a 
null value

	aa(bv)] b is a null flag. v is the value if applicable


I'd prefer unambiguous ones for the sake of completeness.

Cases where this may be important:
1) password: none or unknown
2) software flags: none or unknown
Also empty value is often used to specify default, which is not unknown.

Additionally, we might want to consider blob streaming interface as per 
Jamie's suggestion.

Also, I'd like to eventually revisit thumbnail stuff. I don't think current 
thumbnail spec and vfs/kio can e.g. provide thumbnails for stuff embedded 
into documents. At least our solution is going to be more generic and also 
easier to use for clients. But this is not top priority.

> 5. Session Properties search.blocking and search.live

It's good if bindings actually make it easy to go async.

> 6. Introduce search.readonce

Not clear just how sizable is the benefit. At least introducing it won't hurt.

> 7. Rename CountHits to GetHitCount

No problem.

> 8. search.maxhits

Proposed by Jos, so I don't interfere.

> 9. Split out vendor.fieldnames

Could be hard to implement. I'm not sure it's always easy to enumerate all 
supported fields and classes due to plug-in architecture of most analyzers.

> 10. Use uint Instead of Int Where Applicable

Ok.

>XML/INI

Agreed to install both via convertors.

-- Evgeny