Simple search API proposal, take 2

[Mikkel Kamstrup Erlandsen]

2007/1/15, Jamie McCracken <jamiemcc at blueyonder.co.uk>:
>
> Mikkel Kamstrup Erlandsen wrote:
> > The HitID would be opaque, so any server could use the uri if it wanted
> > to do that.
>
> I was thinking of the clients!


The clients! Does anybody think of the clients!

>
> >
> >     If a HItID is used it could place extra burden on the client to
> manage
> >     HitID->URI transfers. I guess looking at real world apps and their
> needs
> >     will determine which is more suitable...
> >
> >
> >
> > I don't think I understand the complications... What is the problem in
> > requesting the uri property of the hits?
>
> if the live signals (HitAdded, HitRemoved) only contained HitID and not
> URI then clients would need to manage the HitID->URI relationship
>
> On the other hand maybe the signals should send both HitID and URI so
> allowing the client to manage them in either fashion?


Can we expect every object to have an uri? What about fx. browser bookmarks
or <insert odd example>? Of course the server could make up some dummy uri,
but then uris would be opaque types anyway, and we might just call them
HitIds...

The extra complication introduced by the map id->uri is negligible I think.
At least in gtk you'd probably keep stuff in columns in a TreeModel anyway
and you could look one up just as easily as the other. Especially since we
are talking about the live api I think the apps has to do some book keeping
anyway...

Cheers
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070115/8083379b/attachment.htm