I want to show with a view technical points, how ZendFW and extjs could be used in eGroupWare and Tine, and at the same time allowing Tine as a user interface draft to run in parallel to the existing web GUI.
A motivation for this approach would be: - joint development with the current trunk - ability to include it as an optional interface in the next release I'm not aiming to be complete, just emphasizing a view key points: a) Extjs is best suited to talk to it's backend via JASON. If the jason interface would be implemented on top of the existing business object, like eg. the xmlrcp, SyncML or GroupDAV interfaces, it could be uses in parallel with the existing WebGUI on every trunk installation. It would cost a few percents of performance, but would allow a close collaboration in the development of eGroupWare and Tine. On a long run, when the existing webgui would not be used anymore, the business objects could get more optimized towards the needs of the jason interface. b) Parts of our API are pretty old (based on phplib) and would benefit a lot, from using the ZendFW as it's underlying layer. The key point would be to still provide the exiting interface via an egw object instantiated at $GLOBALS['egw']. I know one points was to save api round trip time in jason or more general api requests, by not instantiating every sub-class, as it's done at the moment. This could easily archived with php5.1, by making the class var (in which the sub-objects get instantiated) private and provide a getter method, to instantiate it, if it's not already done, and then return the private var. c) The existing egw_db class could use php's new pdo system or the equivalent ZendFW class, instead of ADOdb. That might even provide better performance for the existing code and at the same time allow new code to use the ZendFW or PDO class directly. If the rest of the API is not using the egw_db class (instantiated in $GLOBALS['egw']->db) and some key components like the so_sql class get's ported to use ZendFW/PDO direct, the above mechanism (see b) would avoid to instantiate it at all. If some other code would assume it's simply there, the getter would kick in and provide it for them. As I said before, I'm not aiming to be complete, I just want to show that there is a technical way how Tine could work within eGroupWare. ------------------------------------------------------------------------ Before someone now gets the idea "Ralf is finally showing some reason", I have to destroy this illusion: - the above is not a new idea - I stated it several times on the lists, thought most people seems to ignore it - it was part of that talk in Kirchheimbolanden, Lars always mentions before saying "Ralf&Nigel disagreed with every single point we made" Again as I said before, the conflict is NOT about a technical solution, it's about a dogmatic approach in what's now called Tine. On a deeper psychological level it is probably also about ownership and being part of something, which leads to the conclusion: we can not use or support existing code or interfaces. I hope I could show there's lots of room for compromise and a fruitful close work together with the people behind Tine. After reading all the mails my only doubt is, there's no will ... Ralf PS: that's a personal statement from developer Ralf and not an statement of the eGroupWare admins -- Ralf Becker eGroupWare Training & Support ==> http://www.egroupware-support.de Outdoor Unlimited Training GmbH [www.outdoor-training.de] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 (0)631 31657-0 ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ eGroupWare-core mailing list eGroupWare-core@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/egroupware-core
