[Kss-devel] API change in base2 vs. service layer

[Balazs Ree]

On Mon, 10 Mar 2008 18:57:02 +0100, Jeroen Vloothuis wrote:

> Balazs Ree wrote:
>> You are banging on open doors! The proposal for this is on launchpad
>> since quite some time:
>>   
>>   
>> I really remember having discussed this with you personally on more
>> occasions, but from your reaction it seems that I may be wrong.
> I am sorry if I came across as being the inventor of the idea. We indeed
> discussed this at some time. My memory is not the most reliable in the
> world so please blame it on that  :-)

I don't claim to be the originator of the idea about the "service layer", 
on the contrary, I believe we came to it together during previous 
verbal discussions with several developers.

I am rather thinking about a way that could assure that our blueprints 
become more visible for ourselves.

>> Besides the implementation of the service layer, the branch contains a
>> generic refactored implementation of the entire kukit plugin system, as
>> well as several very important code cleanup and a few algorithmic
>> speedups as well.

The service-layer branch is now targeted to 1.5 (current trunk), since 
there is no way to get it to 1.4 that is closed now.

About a partial backport, sure it would be possible but I am not sure if 
this would be good, for the following reasons:

- The main improvement of the service-layer branch is that it implements 
a single registry that handles all registration that depends on 
javascript source code. Then it bases the service interface (that we 
currently discuss) and all the other kss plugin registry as well, on top 
of a single implementation. If we only port back the service interfaces 
(that is, interfaces.js and service.js) we end up with more code without 
most of the expected benefits.

- Indeed the branch also brings a lot of small cleanups and fixes in the 
code. These became necessary one by one, during I implemented the main 
goals. In this sense this can be thought of a minimal set of refactoring 
that became necessary. I am afraid if we bring in a few things from the 
branch, we will end up needing the whole set of changes.

So I would suggest, that instead of backporting the whole service layer 
implementation to 1.4, we simply hardcode the swithching between the old 
and new base2 api, in the very same way as we do the swith between the 
old cssQuery and base2 (the way we imnplemented it together in our mini 
sprint in Amsterdam). This is just a few lines can happen on both 1.2 and 
1.4 branches. I would volunteer to do this asap, and I would be very glad 
if you could elaborate on the code after this.


Best wishes,


-- 
Balazs Ree