How can eGroupWare work with ZendFW and extjs

[ralfbecker]

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 [phone]

-------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

[Lars Kneschke-2]

"Ralf Becker" <RalfBecker@...> 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
>
> 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.

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.

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.

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.

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

I wish you a happy 3rd advent too. ;-)

--
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:l.kneschke@...
Web: http://www.metaways.de
Tel: [phone]
Fax: [phone]
Mobile: [phone]

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@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

[Lutz Falkenburg (irrsinn.de gmbh)]

Am 15.12.2007 um 23:02 schrieb Lars Kneschke:
>
>
> 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
>

Would be really great if you stop propaganda for tine20.org - thx!

Lutz

-------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

[ralfbecker]

Hi Lars,

Lars Kneschke schrieb:
> "Ralf Becker" <RalfBecker@...> 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 [phone]


-------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

[Lars Kneschke-2]

"Ralf Becker" <RalfBecker@...> 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:l.kneschke@...
Web: http://www.metaways.de
Tel: [phone]
Fax: [phone]
Mobile: [phone]

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@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

[Lutz Falkenburg (irrsinn.de gmbh)]

Am 16.12.2007 um 14:07 schrieb Lars Kneschke:
>>
> The current eGroupWare api is slow. The current way of handling  
> sessions and
> how the base classes get initiated is far from being optimal.
>

Far away from optimal - aha - we have a Server here with 10 egw  
instances, 420 domains, round about 10.000 Mailaccounts and during  
worktime there are round about 150-200 Users working with these egws.  
Our own egw runs there and we have site recreation times from 2-2.5  
seconds. This is much faster as alle the other systems we are testing  
from time to time.

The secret to speed up the server was ram. At the moment we use a dual  
xenon intel machine with 6 GB ram and a 64 bit suse linux.

The mistake was made by using a vmware on a lowend laptop....


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

I do not now why you are focused on JSON. There are several tests  
showing that JSON isn't that fast comparing with XML. There are  
several discussions going on showing the limitations of JSON. They  
also show thaht it depend on your knowledge creating intelligent code  
by your own like a read/writebuffer depending on your needs. This  
beats JSON all the time because is not as flexible as XML is.  Another  
point is the difference between flexibility of JSON and XML. This is  
what I have understood reading the first 100 arcticles wich comes up  
if you google: JSON performance. Seems to be very interesting....

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

When thinking about changing base technologies in egw why not talking  
about FLEX? FLEX seems to be the better choice?! Did you take a look  
at it?

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

Time to repeat it again. If everything is unclear why are you acting  
as you did?
Wouldn't it be better to finish a  proof of concept before announcing  
your project as the future of egroupware?

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

Yes, as you did - make your own project if you see now future in egw.

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

No - you did NOT a proof of concept. You telling us you are doing but  
in fact you tried to overtook the whole project - thats a little  
difference!

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

Yes. Everyone of you have his own ideas but there was no need grepping  
the egroupware20 domain. I mention this once more because you by  
yourself mentioning the past - so please do not forget things you have  
done!

Regards Lutz

>
> --
> 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:l.kneschke@...
> Web: http://www.metaways.de
> Tel: [phone]
> Fax: [phone]
> Mobile: [phone]
>
> 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@...
> https://lists.sourceforge.net/lists/listinfo/egroupware-core

-------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

[ralfbecker]

Hi Lars,

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

Lars Kneschke schrieb:

> "Ralf Becker" <RalfBecker@...> 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 [phone]

-------------------------------------------------------------------------
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@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core

[Lars Kneschke-2]

"Ralf Becker" <RalfBecker@...> schrieb:
> 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.
Did you ever try to work with a gui application with is "just" a little bit
to slow? That's nothing a user would accept. Either you have a website where
the user expects to wait(aka eGroupWare 1.4) or you have a "real gui"
application (aka Tine 2.0) where you don't expect any delays.

> 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.
It doesn't solve the problem. It just hides the symptoms.

> 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 ...
Because it did not work reliable in any environment. The current situation
is very dependent on the underlying PHP version and/or configuration.

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

I don't want start that "who said when what" game again. I don't think that
it brings us any further.

The situation is very simple. We are providing a proposal how we think the
next major release of eGroupWare could work/look like.
If you like to work together with us, fell free to do so. Everyone is
welcome.
If you don't like to work together with us, fell free to do so too.

But don't blame us, while we are trying to fix the structural problems of
eGroupWare.

--
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:l.kneschke@...
Web: http://www.metaways.de
Tel: [phone]
Fax: [phone]
Mobile: [phone]

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@...
https://lists.sourceforge.net/lists/listinfo/egroupware-core