2007/1/15, Jamie McCracken <<a href="mailto:jamiemcc@blueyonder.co.uk">jamiemcc@blueyonder.co.uk</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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!</blockquote><div> The clients! Does anybody think of the clients! </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > >     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?</blockquote><div> 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...  </div>Cheers Mikkel </div>