[Xesam] Xesam 1.0 vs Xesam 2.0
Mikkel Kamstrup Erlandsen
mikkel.kamstrup at gmail.com
Wed Oct 15 14:47:18 PDT 2008
2008/10/14 Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>
> 2008/10/7 Arun Raghavan <arunisgod at gmail.com>
>> On Tue, Oct 7, 2008 at 5:35 PM, Mikkel Kamstrup Erlandsen
>> <mikkel.kamstrup at gmail.com> wrote:
>> > Yes, it makes sense to keep the breakage between 1.0 and 2.0 as
>> > minimal as possible.
>> My main thoughts on this ("borrowed", as you can no doubt see):
>> 1) Release early, release often: get the spec out and let people have
>> something stable to use
>> 2) Make one to throw away: it's okay if some things need to change
>> radically over the API after the first version. If comaptibility can
>> remain, that's good, but let's deal with that particular problem when
>> we get to it. As Mikkel says, if there is a compelling reason to use
>> the newer API, clients will get (re)written switch to it. And there
>> are always ways to make that transition less painful.
> I understand this as agreement to some degree...
> Based on the responses here I'll try and add the proposal where
> SearchChanged signal passes along the relevant content- and source
> categories. Then when we have it written down it might be easier to discuss.
I flushed my mind onto http://xesam.org/main/Drafts/LiveAPIChanges before I
am starting to write it to the spec.
Please note that I shifted away from the SearchChanged version passing in
the content and source categories affected, for the reason stated in the
last paragraph of the section entitled "The SearchChanged Signal".
Please comment or forever hold your peace (no I did not say "piece" you
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Xesam