Final Project status of Kontact-scripting

[Iain Dooley]

hi there Kun Xi,

your project looks really amazing!! in fact, i've never used Kontact, 
but I am definately going to install it to test out your program!! 
congratulations.

iain

 > Message: 3
 >Date: Thu, 1 Sep 2005 00:22:48 -0400
 >From: Kun Xi <bookstack at gmail.com>
 >Subject: Final Project status of Kontact-scripting
 >To: Till Adam <adam at kde.org>, DanielMolkentin <danimo at kde.org>,
 >	Reinhold Kainhofer <reinhold at kainhofer.com>, kde-soc at kde.org,
 >	Summer-Accepted-2005-NH at googlegroups.com
 >Message-ID: <3c4f5c7005083121223a9dd394 at mail.gmail.com>
 >Content-Type: text/plain; charset=ISO-8859-1
 >
 >Hello mentors,
 >
 >Here is the final status report:
 >
 >      Summary for Kontact-scripting
 >
 >The original motivation of this project is to implement GTD( Get
 >things done) in Kontact via automated script add-ons. KJSEmbed is
 >selected as the script engine for the sake of the simplicity of
 >JavaScript. Our approach starts from a forked Kontact suite codebase,
 >then script/add-on[1] features are added step by step. The original
 >proposal "Common scripting/plugin subsystem for Kontact" can be
 >accessed from here :
 ><http://developer.kde.org/summerofcode/kontactscript.html>, current
 >SVN is hosted in:
 >$KDE_SVN/branches/work/soc-kdepim-scripting
 >
 >
 >Achievement
 >
 >- Singleton script engine.
 >
 >A singleton KJSEmbedPart is wrapped in the libkdepim, so it is quite
 >easy to add scripting feature to any application in Kontact suite. For
 >the case of Kontact, if the component is loaded as a part(i.e the
 >component is in the same address space as the host), kontact can
 >access component's script namespace. Otherwise, they have to talk via
 >DCOP interface. How to hide the difference to the script developer is
 >one of main challenges in the future development.
 >
 >- Easy-to-use object proxy template
 >
 >The main contribution of this project, in my opinion, is the
 >development of KABProxyImp class. This template is inspired by Kst
 >project. It encapsulates all routine procedures to expose one C++
 >native object to the script namespace, property, method and object
 >construction are fully supported. The derived class only needs to
 >implement few necessary functions:
 >  put/get if property is supported
 >  call if method is supported
 >  construct if the object construction is supported
 >
 >Please take a look at the $TOP_DIR/libkdepim/kabproxy_imp.h and one of
 >the example: $TOP_DIR/kaddressbook/addressee_imp.(h|cpp). If you want
 >to add the scripting feature to your own application, KABProxyImp
 >could be a good start for you.
 >
 >
 >- Intuitive namespace management
 >
 >Each component exposes all its objects to one specific namespace, that
 >would help to prevent name confliction. For example, KMail will expose
 >the following objects/methods:
 >
 >Mail
 >  |_ Mail.Inbox
 >  |_ Mail.Outbox
 >  |_ ...
 >  |_ Mail.Message -- the message object which can be constructed via
 >new keyword.
 >
 >So all KMail-specific scripts can be reused in the Kontact application.
 >
 >- Poor man's debugger
 >
 >Script debug is supported via JSConsole. The script developer can
 >output the debug information by calling "println" function, then
 >checks the standard error to troubleshoot the problem. JSConsole also
 >provides a interactive console for the developers.
 >
 >
 >Future work
 >
 >Reture of the Signal/Slot
 >
 >Signal/slot mechanism is implemented by simply exposing the Qt object
 >via addObject method[2] in the pilot development. This implementation
 >has lots of disadvantages: only slot function can be accessed from the
 >script; we lose the control of the object; etc. Current implementation
 >needs to "portmap" the signal/slot from internal object to the
 >external proxy.
 >
 >Refactor, Refactor, Refactor
 >
 >Never hesitate to refactor the code if it not simple. Currently, all
 >the call function in KABProxyImp-derived class is not so beautiful, we
 >need to figure out a more efficient way to validate the argument.
 >
 >Security
 >
 >An preference page should be added to customize whether the add-ons
 >are enabled or disabled. Futher feature would include security level:
 >if one add-on wants write privilege in the read-only security level,
 >the user is prompted to permit or deny this operation.
 >
 >Load on-demand
 >
 >When Kontact script wants to access Mail.Inbox, at that time, KMail
 >component is not loaded, the script engine throws an exception, the
 >native host would catch the exception and load KMail component and
 >continue the script. In a word, more interactivities should be
 >supported between the script engine and native host.
 >
 >
 >DCOP support
 >
 >Hide the difference between the DCOP and Singleton script engine to
 >the script developer.
 >
 >
 >Acknowledge
 >
 >Special thanks to google soc project, it provides such a nice
 >opportunity for me to read high quality open source code, otherwise, I
 >would never have the motivation to dig into what's inside the hood of
 >the Kontact. Thanks to my mentors and KDE developers, I always could
 >get help from all of you whenever I knock the door,
 >#kde-devel at freenode.org. And thanks to my wife, Angela, I really
 >appreciate your love and patience while I kept working for this
 >project.
 >
 >
 >
 >[1] Plugin has been used in Kontact source code to indicate the parts
 >(aka kmail, korganizer), to avoid confusion, we use Add-on to indicate
 >any external scripts that can be loaded during run-time to implement
 >some specific function.
 >
 >[2] Framework for embedding the KJS Javascript Interpreter
 ><http://xmelegance.org/kjsembed/classdocs/index.html>
 >
 >
 >