Hi Lars, Lars Kneschke schrieb: > "Ralf Becker" <[EMAIL PROTECTED]> schrieb: >> 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
It's sad, that you cant see any motivation in that :-( >> 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. > > We tried it. Really. It would have been the easiest way. Cornelius tried to > write an ExtJS based addressbook application which should use the existing > XML/RPC interface. But it wasn't doable because it would have required to > rewrite to much of the current XML/RPC interface. It would have been to much > wasted time, as JSON is the preferred communication protocol. I never said you should try xmlrpc, I said base the jason interface on the business objects, as eg. the xmlrpc interface is. > On the other side eGroupWare 1.4 is simply to slow for such kind of > interfaces. A JSON interface to the current codebase of eGroupWare 1.4 would > very likely not get accepted by the users. A JSON interface requires quick > server responses. And that's something which is not possible with the > current codebase. It's hard to believe, as the business objects of the applications are just php around some database queries. I also made a statement about the API, which you choose to ignore. > http://www.tine20.org/wiki/index.php/What_was_wrong_with_eGroupWare_1.x%3F > http://www.tine20.org/wiki/index.php/Doing_a_performance_analysis_of_a_PHP_application > > >> 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. > > As you can see it would be very easy to add layers of backward compatibility > to our proof of concept code any time very easily. We just need to know, > which kind of backward compatibility we need. Thought you lost me, with "As you can see it would be very easy to add layers of backward compatibility", I cant see that anywhere in the Tine code. About the required interfaces for backward compatibility, it's called eGroupWare API ;-) > But the main problem for the future of eGroupWare are not point a,b or c. > They could all be solved easily by us. But we can't solve the problems of > eTemplate. That you cant solve it, does not necessarily mean: - it can not be solved - you can have no backward compatibility on API level - you are forced to drop all existing code > I wish you a happy 3rd advent too. ;-) To you and Conny and your families too :-) Ralf -- 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
