Dear List I am thinking of writing a Tutos frontend for Zope. Would that be of any interest? \Oliver
Whats is Tutos? -aj ----- Original Message ----- From: "Oliver Marx" <Oliver@tekk.dk> To: <zope@zope.org> Sent: Tuesday, August 13, 2002 13:31 Subject: [Zope] Tutos
Dear List
I am thinking of writing a Tutos frontend for Zope.
Would that be of any interest?
\Oliver
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
www.tutos.org \Oliver
-----Original Message----- From: Andreas Jung [mailto:lists@andreas-jung.com] Sent: 13. august 2002 13:36 To: Oliver Marx; zope@zope.org Subject: Re: [Zope] Tutos
Whats is Tutos?
-aj ----- Original Message ----- From: "Oliver Marx" <Oliver@tekk.dk> To: <zope@zope.org> Sent: Tuesday, August 13, 2002 13:31 Subject: [Zope] Tutos
Dear List
I am thinking of writing a Tutos frontend for Zope.
Would that be of any interest?
\Oliver
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
--- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 02-08-2002
Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.381 / Virus Database: 214 - Release Date: 02-08-2002
Oliver Marx wrote:
Dear List
I am thinking of writing a Tutos frontend for Zope.
Would that be of any interest?
\Oliver
hi oliver, what are the benefits & the surplus from this rewrite? storing your data still in MySQL [or any other relational database] and simply replacing PHP-web-interfaces with Zope/Python-Interfaces is a lot of work & maintainance for a long time [to be in sync with the Tutos-guys] without any significant advantages, isn't it? switching the database-backend to ZODB would be interesting [maybe a 'proof on concept' for the power of ZOPE], but is even more work for one person. maybe we should think about starting a TeamWare-Project for ZOPE from the scratch...;-) cheers, maik -- Maik Jablonski __o www.zfl.uni-bielefeld.de _ \<_ Deutsche Zope User Group Bielefeld, Germany (_)/(_) www.dzug.org
Well First of all I don't think that I would use the ZODB for a TeamWare project. TeamWare will if used generate a lot of data and this is AFAIK not what the ZODB is designed. But then again - I could be wrong. With that said and with all the debate there has been around Intranet and Zope - maybe we should consider making a framework for that? TeamWare would just be a part of it. \Oliver Maik Jablonski wrote:
Oliver Marx wrote:
Dear List
I am thinking of writing a Tutos frontend for Zope.
Would that be of any interest?
\Oliver
hi oliver,
what are the benefits & the surplus from this rewrite? storing your data still in MySQL [or any other relational database] and simply replacing PHP-web-interfaces with Zope/Python-Interfaces is a lot of work & maintainance for a long time [to be in sync with the Tutos-guys] without any significant advantages, isn't it?
switching the database-backend to ZODB would be interesting [maybe a 'proof on concept' for the power of ZOPE], but is even more work for one person. maybe we should think about starting a TeamWare-Project for ZOPE from the scratch...;-)
cheers, maik
Oliver Marx wrote:
Well
First of all I don't think that I would use the ZODB for a TeamWare project. TeamWare will if used generate a lot of data and this is AFAIK not what the ZODB is designed. But then again - I could be wrong.
that's right for very, very, very large & active teams... packing the ZODB once or twice a day [or every hour] should avoid the data.fs from growing too big. maybe undoable transactions are quite funny for a groupware-system... so: I'd prefer the ZODB even for Group/Teamware-systems...;-)
With that said and with all the debate there has been around Intranet and Zope - maybe we should consider making a framework for that? TeamWare would just be a part of it.
maybe we should walk through the products-lists at zope.org and integrate the promising ones [for groupware-functionality of course] under a single [interfaced] framework... cheers, maik
Maik Jablonski wrote:
Oliver Marx wrote:
Dear List
I am thinking of writing a Tutos frontend for Zope.
Would that be of any interest?
\Oliver
hi oliver,
what are the benefits & the surplus from this rewrite? storing your data still in MySQL [or any other relational database] and simply replacing PHP-web-interfaces with Zope/Python-Interfaces is a lot of work & maintainance for a long time [to be in sync with the Tutos-guys] without any significant advantages, isn't it?
switching the database-backend to ZODB would be interesting [maybe a 'proof on concept' for the power of ZOPE], but is even more work for one person. maybe we should think about starting a TeamWare-Project for ZOPE from the scratch...;-)
cheers, maik
Maik Jablonski wrote:
Oliver Marx wrote:
Well
First of all I don't think that I would use the ZODB for a TeamWare project. TeamWare will if used generate a lot of data and this is AFAIK not what the ZODB is designed. But then again - I could be wrong.
that's right for very, very, very large & active teams... packing the ZODB once or twice a day [or every hour] should avoid the data.fs from growing too big. maybe undoable transactions are quite funny for a groupware-system... so: I'd prefer the ZODB even for Group/Teamware-systems...;-)
Ok - I'm not 100% aware of how the ZODB work.
With that said and with all the debate there has been around Intranet and Zope - maybe we should consider making a framework for that? TeamWare would just be a part of it.
maybe we should walk through the products-lists at zope.org and integrate the promising ones [for groupware-functionality of course] under a single [interfaced] framework...
cheers, maik
That would make a good starting point. \Oliver
Maik Jablonski wrote:
Oliver Marx wrote:
Dear List
I am thinking of writing a Tutos frontend for Zope.
Would that be of any interest?
\Oliver
hi oliver,
what are the benefits & the surplus from this rewrite? storing your data still in MySQL [or any other relational database] and simply replacing PHP-web-interfaces with Zope/Python-Interfaces is a lot of work & maintainance for a long time [to be in sync with the Tutos-guys] without any significant advantages, isn't it?
switching the database-backend to ZODB would be interesting [maybe a 'proof on concept' for the power of ZOPE], but is even more work for one person. maybe we should think about starting a TeamWare-Project for ZOPE from the scratch...;-)
cheers, maik
Oliver Marx wrote:
TeamWare will if used generate a lot of data and this is AFAIK not what the ZODB is designed. But then again - I could be wrong.
I think you are ;-) 14GB is a lot of data in my books and I've had ZODB's up to that size. What gave you that impression? cheers, Chris
My train of thought: Locomotive: SQL servers are designed for large datastructures. Wagon1: ZODB is not a *well known* player on that field. Wagon2: I have not looked/seen *any* documentation on how ZODB is designed. So I'm a little sceptic. \Oliver Chris Withers wrote:
Oliver Marx wrote:
TeamWare will if used generate a lot of data and this is AFAIK not what the ZODB is designed. But then again - I could be wrong.
I think you are ;-)
14GB is a lot of data in my books and I've had ZODB's up to that size.
What gave you that impression?
cheers,
Chris
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Oliver Marx wrote:
My train of thought:
Locomotive: SQL servers are designed for large datastructures.
Wagon1: ZODB is not a *well known* player on that field.
Wagon2: I have not looked/seen *any* documentation on how ZODB is designed.
So I'm a little sceptic.
\Oliver
Hi Oliver, I've too thought about writing a frontend to the tutos database in zope. Sadly I didn't have the time to even begin with something since then, but I really like the idea. My ideas were to completly use the database structure of tutos, including users, but I haven't checked if this is viable. In any case, what I have seen from the structure of tutos' tables, there are a lot of references in there. This is one reason why I wouldn't want to use the ZODB for storing the data. And it doesn't make sense IMO to reinvent the wheel, again and again like the plethora of unfinished groupware project for zope and elsewhere. I even wrote an email to the author, and he quite liked the idea, because he always had portability of the frontend in his mind. Drop me an email about how you would like to go on about this, and I'll see what I can do to help you. cheers, oliver
Oliver Marx writes:
My train of thought:
Locomotive: SQL servers are designed for large datastructures.
Wagon1: ZODB is not a *well known* player on that field.
Wagon2: I have not looked/seen *any* documentation on how ZODB is designed. Not sure, that I get what you mean with "design".
But, there is ZODB documentation: * an UML model (this is a design document) * quite a good description named "zodb3.html/pdf". The latter document tells you that ZODB is designed for applications with a low ratio of writes to reads. It does not tell you how many objects you can *practically* store in the ZODB (the theoretical limit is very high, something like 256**8). But, I did not yet see such assurancies for SQL servers neither... Dieter
participants (6)
-
Andreas Jung -
Chris Withers -
Dieter Maurer -
Maik Jablonski -
Oliver Bleutgen -
Oliver Marx