Overview : ========== The purpous is to have generic desktop integration architecture that allow Nuxeo5 users to edit files directly with the native local editor : - the user clicks on "edit on line" link - the associated editor is started on the client side - the editor must comunicate with Nuxeo server to : - download the file to edit - acquire lock if needed - save the file back to nuxeo server - create new version if needed - release lock if needed - ... This somehow what we already have with current version of LiveEdit. The purpouse is : - to define a more generic architecture : be able to have editor plugins to support other editors that MSOffice2003 - to clearly define the WS interface used by editors Global Architecture : ===================== Client side : ------------- On the client side, we have at least 2 separated components : BootStrap / Launcher : This component will "intercept the click" on "Edit online" link on the browser side and : - fetch some informations about the file to edit : DocumentModel reference + fieldName + mime-type - fetch some information about the user session (at least JSESSIONID) - start the Editor plugin that will do the real job Editor Plugin : The editor plugin will be in charge of the editing process : - handle pre-edit actions : lock, checkout ... - download the file locally - edit the file - save back to nuxeo and do post edit action : unlock, checkin, validate ... At this point, we already see a possible problem / question : the communication for pre-edit/post-edit action will probably be the same for all plugins (MSOffice, OOffice, ...), but we may want the UI to be different depending on the editor plugin. So we have mainly 3 choices : - factorize all communication in the Launcher : on generic UI of checkin/checkout, lock/unlock ... => no integrated dialog inside the editor - factorize all communication in the Launcher : let the Launcher expose an API for the Editor, so that Launcher handles the communication and the editor handles the UI => Needs a communication API between the Launcher and the editor (implies Launcher and Editors use the same language) - limit the Laucher to authentication and plugin selection task, the editors will handle the communication => All Editors will have to reimplement the communication layer I would go for solution 3 : this will introduce some code duplication, but I think this is the most simple and flexible solution. When we will have several Editors Plugins, depending on the laguages used, we will see if we can factorize the code in the launcher or in a helper lib Server side : ------------- On the server side we will have a dedicated WebService. The WebService will mainly handle 2 types of methods : - download/upload file - fetch available actions / do actions Actions availables on the document may depend on the client project specifications, and it's important that it is totally transparent for the client plugin UI : we don't want to build a version of the clients plugins for each project. So the idea, as in existing LiveEdit, is that the WebService will provide the client a simple list of actions, the client will simply display availables actions, and eventually ask the server to execute them without knowing the underlying logic. This "action logic" is somehow close to what we already do in the web layer, an action is : - an action id - a label : generated on the server side If several actions can be done (like checkout + lock), then it will be presented as 3 actions : chekout, lock, checkout_and_lock. This way we won't have to handle associations conditions on the client side : the user can always select one and only one action : none / lock / checkout / chekout_and_lock We will also need a server side module for the bootstrap client, see below. The Bootstrap client module : ============================= init : ------ The Bootstrap module must intercep the click on the "online edit" link. This can be done in 2 ways : - using a dedicated mime-type that should be associated with the Bootstrap executable => this is what was done with previous version of LiveEdit - using a dedicated protocol handler => cleaner and avoid download dialog (but more complexe) We will use the solution of the protocol handler. Then the "online edit" link will be something like : nxedit://server:port/nuxeo/nxedit/repo/docid/fieldname. The protocol handler will be called by the OS/Browser and receive the url. It will then call the URL : http://server:port/nuxeo/nxedit/repo/docid/fieldname. At this point, I hope the protocol handler can retrieve the JSessionID ... to be checked. Bootstrap data download : ------------------------- The http://server:port/nuxeo/nxedit/repo/docid/fieldname calls returns a bootstrap file. This file contains : - repo name - document id - fieldname - associated fileName - associated mime-type This file will be XML. Authentication management : --------------------------- As the Bootstrap client needs to do a http call, it needs to be able to authenticate. There are 2 solutions : - reuse JSESSIONID - use basic authentication => means the bootstrap client has a configuration file or registry keys to store login/password entered by the user. Editor launch : --------------- Based on a configuration file containing mime-type/editor mapping, the bootstrap module will launch the editor. The most simplier and neutral way of doing that is just executing the editor plugin passing it a bootstrap file. This file will be the same as the one returned by Nuxeo5 server with additionnal authentication information : JSESSIONID and Login/Password. The Bootstrap server module : ============================= The Bootstrap server module will be a simple Seam component. The Editor : ============ The editor process will : - receive and read the bootstrap file - start the client editor (MSOffice via COM interop interface, OOffice via ??? ...) - call WS to get list of pre-edit actions - display a dialog for letting user select action - call WS to download the file - call WS to get list of post-edit actions - display a dialog for letting user select action - save and upload the file to Nuxeo Server - terminate For MSOffice, this Editor process could be seperated in 2 parts : - the bootstrap part : 2 first steps - the pure editor part : all other steps => This could be implemented as an office plugin The WebService : ================ This Web Service will be exposed by a dedicated EJB3. It will be pretty much like the existing FileManagerWS : but cleaner code with better wsdl. I propose to call it ExternalEditWS (feel free to propose a sexier name :) ). API : ----- For now here is what I see in the API : - Map getPreEditActions(String sid, String repo, String docRef, String fieldName) : send possible action for pre-edit - Map getPostEditActions(String sid, String repo, String docRef, Stringe fieldName) : send possible action for post-edit - Boolean doAction(String sid, String repo, String docRef, String fieldName,String actionId) : execute action, returns true if client must re-read the file from server - getFile(String sid, String repo, String docRef, String fieldName) - saveFile(String sid, String repo, String docRef, String fieldName, Blob blob) - String getProperty(String sid, String repo, String docRef, String fieldName) - String setProperty(String sid, String repo, String docRef, String fieldName, String value) Authentication : ---------------- The call to WS must be authenticated. 2 ways for doing that : - reuse the JSESSIONID : get UserPrincipal and Login context from the incomming request => call with sid=null - explicitly create a session and forward it in each call => call with non null sid