How can eGroupWare work with ZendFW and extjs

Ralf_Becker_6 2007-12-14 19:50:23 UTC #1

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-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Lars_Kneschke-2 2007-12-15 22:02:37 UTC #2

“Ralf Becker” RalfBecker@outdoor-training.de 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@metaways.de
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

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

David_C_Rankin 2007-12-16 01:28:02 UTC #3

Lars Kneschke wrote:

“Ralf Becker” RalfBecker@outdoor-training.de 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:

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.

Ralf, Lars,

There are a lot of good creative/innovative ideas floating across the

list associated with the current discussion. One of the difficulties I
see in trying to navigate the current waters is that there is no compass
to be found. We all agree that faster is better, but running faster in
the wrong direction does nothing more than get us lost/off track quicker.

I don't know if this can be done, but what I haven't seen, that I would

like to see, is a set of goals for where egw wants to go that we can
evaluate the competing ideas against. This doesn’t need to be anything
elaborate, formal or detailed, but just something that will help clarify
and define the competing visions for egw. A list of priorities so to speak.

If the competing camps can agree to take 24 hours to step back and list

the goals of what they want to do with egw we would then at least have a
reference point for carrying the discussion forward. None of the ideas I
have seen from either side are mutually exclusive. The difficulty I have
seen is from an inability to evaluate a list of stated goals and
evaluate each item to determine the direction for egw. I think it would
help.

I think a simple list would include goals for:

o backwards compatibility/migration path for exceptions
o exclusive use of in house code/reliance of 3rd party packages
o desire for package responsiveness/client side rendering
o server load/client load
o core packages/supported packages/unsupported packages

This is just 40 seconds of typing, but if everyone would agree to take

24 to hammer this out, I think discussions could move forward.

Each of the resulting issues will have to be discussed. An  example is

the in house code v. reliance on 3rd party packages. There is a lot to
be said for the total control that comes from custom code. There is a
lot to be said for using good off-the-shelf code. However, many people
have been screwed when they have relied on off-the-shelf code only to
have the external coding project tank. The project is screwed at that
point unless the project picks up the left-overs.

Much tension abounds, but keep the focus on "what's good for egw" From

the swirl of competing ideas, each of the developers can and must answer
that question. Not everything has to be done tomorrow. Fighter pilots
and astronauts have a very simple way of staying alive (I know, I
trained the crews of STS-44, 54 and 68 on OBS) It applies here:

Keep the vehicle under control;
Analyze the situation;
Take corrective action.

We are two-engine TAL at this point. See:
http://science.ksc.nasa.gov/shuttle/technology/sts-newsref/mission_profile.html

–
David C. Rankin, J.D., P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Lars_Kneschke-2 2007-12-16 12:34:36 UTC #4

“David C. Rankin” drankinatty@suddenlinkmail.com schrieb:

Ralf, Lars,

There are a lot of good creative/innovative ideas floating across the
list associated with the current discussion. One of the difficulties I
see in trying to navigate the current waters is that there is no compass
to be found. We all agree that faster is better, but running faster in
the wrong direction does nothing more than get us lost/off track quicker.

I don’t know if this can be done, but what I haven’t seen, that I
would
like to see, is a set of goals for where egw wants to go that we can
evaluate the competing ideas against. This doesn’t need to be anything
elaborate, formal or detailed, but just something that will help clarify
and define the competing visions for egw. A list of priorities so to
speak.
Hello David!

You are totally right. I just wanted to write about this yesterday already,
but I got sidetracked because of the 5 children around me. But now they are
watching TV for a short moment, which gives me some spare time.

One thing I totally miss for eGroupWare is the broad vision. For whom do we
develop eGroupWare? What kind of technologies do we like to use? What
features do we like to implement this year, what next year and there after?
Who is responsible for which feature? How do we work together as project?

As we don’t have this vision it is also very hard to decide what is good for
the project and what is not. From my understanding we could also call this
priorities form your point of view.

I can provide such list of priorities in the next 24 hours.

–
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@metaways.de
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

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Milosch 2007-12-16 13:02:24 UTC #5

Lars_Kneschke-2 2007-12-16 13:17:29 UTC #6

“Miles Lott” milos@groupwhere.org schrieb:

The fact is that what exists with tine is an internal company project
proposing to act as the way forward for our open source project. It is a
separate project with a separate development tree and website which are
privately maintained. Its membership is entirely composed of that
company’s employees. Yes, some if not all of those developers are also
members of the egroupware project. But, that alone does not make it
egroupware. The company is entirely within its rights to work in this
way. They are not the only ones doing it, and to a certain extent this
can be beneficial to egroupware. But we should be clear about the
organization as it exists currently.

Our sourcecode is at sourceforge release under the GPL.
Our website is a wiki.
We have a forum where anyone can register itself.
We are communicating openly about our ideas.

I wouldn’t call this privately.

Was is the problem, that we hired Cornelius to help solving the problems of
eGroupWare?

We also stated multiple times why we got forced to choose the way we have
choosen. It’s sad that still ignore these facts.

We also stated clearly that we are working for the eGroupWare project
multiple times.

Also no other deverlopers stated that they don’t like our work.

I absolutely don’t understand you rant.

–
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@metaways.de
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

Milosch 2007-12-16 13:29:39 UTC #7

Jose_Luis_Gordo_Rome 2007-12-16 14:59:14 UTC #8

We need solutions (steps forward), Lars please be more positive about the
admins minds changes (including Ralf roadmap to make egroupware as tine look
without break all). For me and maybe more people I can’t switch to tine (I
like zf and extjs) till have ported projectmanager, tracker, sitemgr, wiki,
kb, timesheet, resources, syncml, links, vfs, custom fields…

Tine people: Because not move your svn code to a egroupware svn new branch
where all current developers can participate and help with the prof of
concept?

It’s the same as now, only within the egw infrastructure (be inside
the project)

Egroupware: Because not create a new site dedicated to development, maybe a
new wiki (for this stuff) on http://dev.egroupware.org? I can help with this
task.

In this new site (clean: as our minds) we can make a clear roadmap
for what we thinks should be the egroupware’s future and discuss "only"
technical points.

All two parts stated the same, the best for all is join efforts and the two
parts are and will be inside the project, but in differents languages.

I wish help the project, as the project (the egroupware software and their
community) helps me every day.
José Luis Gordo Romero

Perhaps it seemed impossible to work with certain others within the
project. But, it was certainly possible to work within the project. There
are 3 elected admins, but I do not recall receiving any requests from you to
bring this up earlier. Actually, you probably didn’t need admin approval to
create a branch in svn or establish a working group in our wiki. So, it
appears that this externalization was decided independently. I don’t think
this is a rant on my part.

This is not about the hiring of anyone at Metaways or Stylite or any other
company [ could be Groupwhere next ]. It is also not really about the
code itself. I just wonder, and perhaps it is only me, why your work is
separated from the project infrastructure? Again, you know that I came to
this late so perhaps I do not understand. I don’t care about personal
differences, because this is normal for any large organization. I really
don’t want to hear names called out anymore as it will never help the
situation. Please take the high road and move beyond that obviously
unfortunate meeting.

Lars Kneschke wrote:

“Miles Lott” milos@groupwhere.org milos@groupwhere.org schrieb:

The fact is that what exists with tine is an internal company project
proposing to act as the way forward for our open source project. It is a
separate project with a separate development tree and website which are
privately maintained. Its membership is entirely composed of that company’s
employees. Yes, some if not all of those developers are also members of the
egroupware project. But, that alone does not make it egroupware. The
company is entirely within its rights to work in this way. They are not the
only ones doing it, and to a certain extent this can be beneficial to
egroupware. But we should be clear about the organization as it exists
currently.

Our sourcecode is at sourceforge release under the GPL.
Our website is a wiki.
We have a forum where anyone can register itself.
We are communicating openly about our ideas.

I wouldn’t call this privately.

Was is the problem, that we hired Cornelius to help solving the problems
of eGroupWare?

We also stated multiple times why we got forced to choose the way we have
choosen. It’s sad that still ignore these facts.

We also stated clearly that we are working for the eGroupWare project
multiple times.

Also no other deverlopers stated that they don’t like our work.

I absolutely don’t understand you rant.

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@metaways.de l.kneschke@metaways.de
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-developers mailing list

eGroupWare-developers@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/egroupware-developers

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-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

–
Saludos
José Luis Gordo Romero

Lars_Kneschke-2 2007-12-16 17:58:39 UTC #9

“Miles Lott” milos@groupwhere.org schrieb:

This is not about the hiring of anyone at Metaways or Stylite or any other
company [ could be Groupwhere next ]. It is also not really about the
code itself. I just wonder, and perhaps it is only me, why your work is
separated from the project infrastructure?

Because of what has been told at the “unfortunate meeting”.

First of all we are unhappy about the current wiki. From our point of view
it is unuseable. You never find what you have entered before. We like to
use Mediawiki. It’s a well know standard anyone is able to work with. This
wish got denied. In the current situation the eGroupWare.org website does
not provide what we need.
So we registered our own domain and did setup our own wiki.

Secondly we liked to play around with a forum. Especialy on the german list
the people often requested a forum.

And then there are people working at Metaways which are no eGroupWare
project member but still should be able to access the svn. This people need
to work, and we can’t wait until they got approved as project members to
work directly against the svn.

If the developers of the eGroupWare project deny our proposal we need to
find a new home anyway. If the developers of the eGroupWare project accept
our proposal we will move immediately to the eGroupWare svn.

Again, you know that I came to this late so perhaps I do not understand.
I don’t care about personal differences, because this is normal for any
large organization. I really don’t want to hear names called out anymore
as it will never help the situation. Please take the high road and move
beyond that obviously unfortunate meeting.

But you know that there is still one thing left open, which needs to get
clearified, before Cornelius and me can forget about this meeting.

–
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@metaways.de
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

Milosch 2007-12-16 18:26:13 UTC #10

Lars Kneschke wrote:

“Miles Lott” milos@groupwhere.org schrieb:

Again, you know that I came to this late so perhaps I do not
understand. I don’t care about personal differences, because this is
normal for any large organization. I really don’t want to hear names
called out anymore as it will never help the situation. Please take
the high road and move beyond that obviously unfortunate meeting.
But you know that there is still one thing left open, which needs to
get clearified, before Cornelius and me can forget about this meeting.

And what is that? If it has to do with anyone’s project membership, we
have stated already that this will not be a point for negotiation. If
we were not clear, let me state it clearly:

No one’s project membership will be up for negotiation until this issue
is settled. They are not going to be tied together in any way. Once we
have an agreement to move forward, then other technical and
administrative issues will most certainly be discussed.

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Lars_Kneschke-2 2007-12-17 11:46:00 UTC #11

“Miles Lott” milos@groupwhere.org schrieb:

No one’s project membership will be up for negotiation until this issue
is settled. They are not going to be tied together in any way. Once we
have an agreement to move forward, then other technical and
administrative issues will most certainly be discussed.

If they are not tied together, why can’t we solve that problem now?

–
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@metaways.de
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

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Lars_Kneschke-2 2007-12-17 11:51:39 UTC #12

“José Luis Gordo Romero” jgordor@gmail.com schrieb:

We need solutions (steps forward), Lars please be more positive about the
admins minds changes (including Ralf roadmap to make egroupware as tine
look
without break all). For me and maybe more people I can’t switch to tine (I
like zf and extjs) till have ported projectmanager, tracker, sitemgr,
wiki,
kb, timesheet, resources, syncml, links, vfs, custom fields…

Tine people: Because not move your svn code to a egroupware svn new branch
where all current developers can participate and help with the prof of
concept?

We stated already multiple times, that we have no problem doing this. But it
would require that any of the developers participating the Tine 2.0 effort
get an account on the svn server of eGroupWare.org. So far the admins did
not respond regarding this issue.

Egroupware: Because not create a new site dedicated to development, maybe
a
new wiki (for this stuff) on http://dev.egroupware.org? I can help with
this
task.

In this new site (clean: as our minds) we can make a clear roadmap
for what we thinks should be the egroupware’s future and discuss "only"
technical points.
Sounds like a good idea.

–
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@metaways.de
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

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Milosch 2007-12-17 12:14:30 UTC #13

Lars_Kneschke-2 2007-12-17 12:18:10 UTC #14

“Miles Lott” milos@groupwhere.org schrieb:

   Lars Kneschke wrote: 
“Miles Lott” milos@groupwhere.org
schrieb:

No one’s project membership will be up for negotiation until this issue
is

settled. They are not going to be tied together in any way. Once we
have

an agreement to move forward, then other technical and administrative
issues will most certainly be discussed.

If they are not tied together, why can’t we solve that problem now?

That’s a little vague. What do you mean?

Why can’t we solve the problem with Nigel Vickers project membership now?

–
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@metaways.de
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

Milosch 2007-12-17 13:10:47 UTC #15

Lars_Kneschke-2 2007-12-17 13:38:40 UTC #16

“Miles Lott” milos@groupwhere.org schrieb:

This is circular argument since it would be included in the part above
where it says “No one”. We, and that means the admin team, have decided
to deal with each issue independently and in order. We do not want to
work like, e.g., the US congress, where thousands of items are combined
into a single piece of legislation to satisfy everyones’ special interests.

Again, we want to resolve the situation with tine first, and as quickly as
possible. Please speak to this with relevance to our prior statements.

What else is unclear regarding Tine 2.0?

–
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@metaways.de
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

Milosch 2007-12-17 13:48:09 UTC #17

Lars_Kneschke-2 2007-12-17 14:15:27 UTC #18

“Miles Lott” milos@groupwhere.org schrieb:

   Please see our prior statements.  Whatever is in there relevant to
tine is what is in there relevant to tine

Do you want to be taken seriously?

We posted our response already.

Please state what is left unclear!

–
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@metaways.de
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

Milosch 2007-12-17 14:23:09 UTC #19

Clearly that was my attempt at humor, Lars… Where is this posted response?

Lars Kneschke wrote:

“Miles Lott” milos@groupwhere.org schrieb:

Please see our prior statements. Whatever is in there relevant to
tine is what is in there relevant to tine
Do you want to be taken seriously?

We posted our response already.

Please state what is left unclear!

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Lars_Kneschke-2 2007-12-17 14:24:14 UTC #20

“Miles Lott” milos@groupwhere.org schrieb:

Clearly that was my attempt at humor, Lars… Where is this posted
response?

Strange timing for humor…

http://www.nabble.com/admin-statement-about-eGroupWare---Tine-relationship-to14346637s3741.html

–
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@metaways.de
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

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers