Re: [eGroupWare-core] How can eGroupWare work with ZendFW and extjs

[Ralf B. <Ral...@ou...>]

Hi Lars,

it's nice to have this more technical discussion :-)

Lars Kneschke schrieb:
> "Ralf Becker" <Ral...@ou...> 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.

I never said there is a jason interface, I only said "base the jason
interface on the business objects". And if you would also consider
working on the API, as I suggested in b+c), it would not be to slow,
thought it's hard to define what is to slow.

Specially if maybe a little bit slower, would allow us to work together
(Tine and eGroupware). I think, a little be less optimal solution, is
absolutely worth implementing, if it allows to cooperate with the
project. If you dont think so, allow me to question your priorities.

>>> 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.

As I already said, I'm absolutely fine with using Zend as an underlaying
layer for the eGroupWare API. I states that multiple time, including the
meeting. I also outlined in this thread how php5.1 features would allow
to avoid loading all objects, by still keeping all current applications
running.

The other big improvement in the round trip time for ajax or jason
requests is, to store the whole eGW environment in the session. That's
available since eGroupWare 1.2. We use it on all our installations,
thought I know you dont use it for some reason ...

> Did you ever had a look at the results on this page?

Sure, I'm reading and following very well what your writing.

> 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.

This argument is total nonsense, any you know it ;-)

The jason interface would not be based on the eTemplate UI, but on the
business object, never calling eTemplate. Please dont start making up
stuff, in a technical discussion!

>>> 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.

I would not call the ability to cooperate and jointly develop in one
project a waste of time!

Btw. if your "proof of concept" was meant to be ever integrated back
into eGroupWare, why for example do you choose to set up an own coding
style for it. Don't tell me that was required by jason ;-)

You make it deliberately hard to integrate your "proof of concept" back
into eGroupWare. It's made to have an all or nothing decision, when it's
done: either you accept everything we done, or nothing.

I find it also hard to believe, that a company is paying 3 developers
for one year to do a proof of concept, and accepting at the same time it
might be simply dismissed. Thought that's not a problem for the project,
but it makes is very clear for me, this was never meant as a "proof of
concept".

>> 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.

Sorry to say, but that unproven argument is really getting boring, to
use your words ;-)

You can not expect everyone immediately stops doing what he planned
since a long time, just because you have a good idea, you want to follow.

I also think, that this thready shows nicely who is not willing to
compromise it's point of view.

> 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.

It is not a question if backward compatibility makes sense. It's the key
to allow us to work together and get a next release out in the usual
timespan.

> 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.

I think you still have to prove, it can be done in a reasonable
timespan, thought we were talking not about a prove of concept can be
done in a reasonable timespan, but an eGroupWare release.

And I will repeat it again, I'm not against ZendFW and ExtJS, or jason
as transport protocol, which you might start recognizing by now.

I wish you a nice Sunday evening :-)

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