"Ralf Becker" <[EMAIL PROTECTED]> schrieb: > Lars Kneschke schrieb: >> 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. There is no JSON interface currently. We need to write it from scratch anyway. But it makes no sense to base a JSON interface on the slow eGroupWare codebase.
>> 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. The current eGroupWare api is slow. The current way of handling sessions and how the base classes get initiated is far from being optimal. Did you ever had a look at the results on this page? http://www.tine20.org/wiki/index.php/Doing_a_performance_analysis_of_a_PHP_application The business logic an eTemplate application is only 10% of the total processing time spent. Without etemplate is is still about 80%. You can not base a JSON based UI on this slow codebase. >> 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 ;-) I know that we have different understandings how to develop software. But we are doing on step after the other. We know how to write good PHP code. We understand PHP very well. And we have a broad team of PHP developers here at Metaways. We know already that we can implement backward compatibility in different areas of eGroupWare. But currently we are working on a proof of concept, with the goal to show the other developers how easily you can build groupware applications on top of ExtJS and the Zend Framework. We need to learn how to write good JavaScript code and how to communicate using JSON. Currently it is totally unclear which kind of backward compatibility is needed, after we have finished our proof of concept. And it is totally unclear which code will be needed in the future. Of course we don't touch this area until we have a clear understanding about what is needed. Everything other would be a waste of time. > 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 Ok. It's time repeat it again. At the meeting in the summer, Nigel and you denied any our ideas because they can't work or did not work in the 80's already. As we asked you to work together with us to modernize eTemplate you also denied to do this, because had other more important things to do for a very long time. And Nigel and you stated that we can not expect that you can take care of our problems. As long as you keep up this kind of attitude, we can only work on the things we can solve ourself. And as I stated above and also already multiple times on the different lists, there is no reason to add backward compatibility later any time or reuse old code. It it makes sense, why not. There is no dogma like you are calling it. We are doing a proof of concept. ==> http://en.wikipedia.org/wiki/Proof_of_concept A proof of concept is by no way a completely working product. And it is also not something set in stone. It's just proof of concept that you can write a JSON application which based on ExtJS and Zend Framework. Something Nigel and you denied that it can work or can be done in a reasonable timeframe. -- Lars Kneschke CTO OfficeSpot.Net Metaways Infosystems GmbH Pickhuben 2-4, D-20457 Hamburg eGroupWare Support: http://www.egroupware-support.net OfficeSpot.Net Collaboration Server: http://cs.officespot.net our proposal for the next major eGroupWare release: http://www.tine20.org E-Mail: mailto:[EMAIL PROTECTED] Web: http://www.metaways.de Tel: +49 (0)40 317031-21 Fax: +49 (0)40 317031-921 Mobile: +49 (0)175 9304324 Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel Handelsregister: Amtsgericht Ahrensburg HRB 4508 Geschäftsführung: Hermann Thaele, Lüder-H.Thaele ------------------------------------------------------------------------- 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
