[Kss-devel] KSS without Zope

[Balazs Ree]

Tue, 08 May 2007 22:05:11 +0200 keltezéssel Jeroen Vloothuis azt írta:

> For server side KSS support we are currently tied to Zope. While basic
> KSS functionality might be easily reimplemented this still hinders
> adoption. To overcome this problem I think it would be good to have a
> basic distribution of KSS at a few levels.
> 
> The first level would be just the Javascript code. This should include
> only the core of KSS (what is now kukit in the repository). It would
> need to available as a packed version preferably with all required third
> party libraries included.
> 
> A second level would be the language specific integration points. This
> would include code for generating the response in the format required by
> KSS. It might also contain some basic abstractions like we have now in
> kss.core. With highlevel abstractions I mean code to generate the
> implemented commands in a nice way. What do you think is basic
> functionality for KSS server side components?


About the python refactorization I would suggest a conservative
approach.

First, I propose to untouch kss.core at the moment and create an
independent package kss.pycore. (That's just the name suggestion, the
point is start with the new package and not moving kss.core.)

What should this package contain?
---------------------------------

- helper for command generation and rendering the response (basically
kss.core.interfaces.IAzaxCommands). As at the moment we are generating
the response with zpt, either tal has to be a dependency, or we need to
rewrite the rendering. Maybe we can just generate it with print, it's
such a simple structure, just an iteration on commands.

- api and commandline for the packing/concatenation.

- ...? maybe nothing else at the moment. but for example the docstring
registry will come here too once it's written.

As you see the most important part to start with, is the command 
generation part, later we can add more things.

As I imagine the javascript would not be part of the pycore package, it
would be needed together with it (as the serving the files is not in the
python part). 


How should it be implemented?
-----------------------------

I suggest that this package should come with a simple but working
example that uses it in another non-zope framework.

After this is done, we can change kss.core in a way that it uses
kss.pycore and get rid of the code there.

Why am I suggesting this? Because our goal is to enable kss in a
non-python environment. Thus a use case implemented that uses the
library is inevital But we don't need to switch over kss.core to use it, 
before we can see it really works.

-- 
Balazs Ree