[XESAM] Search API Update Proposals
phreedom.stdin at gmail.com
Mon Aug 6 13:30:13 PDT 2007
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:
> 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
> 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
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
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
> 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
Agreed to install both via convertors.
More information about the xdg