Re: [Zope] Zope needs this (and Dynamo has it)
Alexander Staubo <alex@mop.no> writes: [snipped]
Zope doesn't have the flashy packaging and sexiness of a product line Dynamo -- which, actually, I strongly urge you (and everybody else in this forum) to experience yourself, before you snap back at my again -- and this affects management decisions. Dynamo is exceedingly sexy, and it boasts the kind of bullshit magic that have management and tech people alike drooling.
OK, but see you're trying to make Linux something it is not. Linux is not about marketing. It is not about world domination. We specifically do not care about this :-) Now, digicool is a company, and they probably DO care about this. Making Zope Free Software is a great way for them -- and us -- to benefit. So your comments should be addressed at them if you want them to make the sale. Not me, a Linux hacker.
As one of my colleagues pointed out, the problem starts with the name. (Somebody out there is hyping what they call Linux' next-generating GUI. And it's called... GNOME. What's wrong with this picture?) I don't care myself, but I recognize the problem.
But see again, Free Software is not about marketing. The name is irrelevant to us. Free Software is about what's *right* and what *works*. We leave the marketing to those that want to do it (such as digital creations, or whomever else). So again, write to digital creations' marketing dept. :-) -- John
John Goerzen wrote:
Alexander Staubo <alex@mop.no> writes:
[snipped]
Zope doesn't have the flashy packaging and sexiness of a product line Dynamo -- which, actually, I strongly urge you (and everybody else in this forum) to experience yourself, before you snap back at my again -- and this affects management decisions. Dynamo is exceedingly sexy, and it boasts the kind of bullshit magic that have management and tech people alike drooling.
OK, but see you're trying to make Linux something it is not. Linux is not about marketing. It is not about world domination.
Ask Linus Torvalds. :) Anyway, Linux is what people do with it. Not what people say about it.
We specifically do not care about this :-) Now, digicool is a company, and they probably DO care about this. Making Zope Free Software is a great way for them -- and us -- to benefit. So your comments should be addressed at them if you want them to make the sale. Not me, a Linux hacker.
I care about making Zope more popular, as there will be more Zope users, more Zope hackers, and better free Zope support. More cool Zope goodies. More Zope related jobs. I care about Zope marketing. Even if you only care about Free software, you care about marketing it, as you care about what's 'right', and therefore you want people to use the right stuff; Free software. Right? :)
As one of my colleagues pointed out, the problem starts with the name. (Somebody out there is hyping what they call Linux' next-generating GUI. And it's called... GNOME. What's wrong with this picture?) I don't care myself, but I recognize the problem.
But see again, Free Software is not about marketing. The name is irrelevant to us. Free Software is about what's *right* and what *works*. We leave the marketing to those that want to do it (such as digital creations, or whomever else). So again, write to digital creations' marketing dept. :-)
Alexander Staubo obviously was interested in Zope marketing. Why tell him 'we' don't do that, while some of us are definitely interested? Free software is about people doing what they want. Let us do want they want and don't speak for me. :) Thanks. Regards, Martijn
Martijn Faassen wrote:
John Goerzen wrote:
We specifically do not care about this :-) Now, digicool is a company, and they probably DO care about this. Making Zope Free Software is a great way for them -- and us -- to benefit. So your comments should be addressed at them if you want them to make the sale. Not me, a Linux hacker.
I care about making Zope more popular, as there will be more Zope users, more Zope hackers, and better free Zope support. More cool Zope goodies. More Zope related jobs. I care about Zope marketing.
(..More Companies packaging, enhancing and distributing Zope and Zope based products) Yes, I care too. And for the exact same reasons. The more popular Zope becomes, the better it is for all of us.
Even if you only care about Free software, you care about marketing it, as you care about what's 'right', and therefore you want people to use the right stuff; Free software. Right? :)
Alexander Staubo obviously was interested in Zope marketing. Why tell him 'we' don't do that, while some of us are definitely interested? Free software is about people doing what they want. Let us do want they want and don't speak for me. :) Thanks.
Yes. Alexander has brought up a very (IMO) relevant issue. It is in the interest of the entire community to make Zope well known and I feel marketing should not be left just for DC to take care of. I see a number of articles/sites about 'app servers' which don't mention Zope but mention others (including some mickey mouse servers I've never heard of). Eg: http://serverwatch.internet.com/appservers.html Why? Maybe Zope isn't talked about at all outside some circles? Altavista shows about 1058 pages linking to zope.org (compare php.net:12,000 ; apache.org:60,000). Why? If nobody does anything, this will take time to change. If we want this to change faster, all of us have to actively market Zope. This involves talking about in appropriate newsgrousps, putting up zope webpages, making Zope easier to learn and use, adding flashy features etc. All this can make a whole lot of difference. Shalabh
[Shalabh Chaturvedi, on Wed, 08 Mar 2000] :: I see a number of articles/sites about 'app servers' which don't mention Zope :: but mention others (including some mickey mouse servers I've never heard of). :: Eg: http://serverwatch.internet.com/appservers.html :: Why? Maybe Zope isn't talked about at all outside some circles? :: :: Altavista shows about 1058 pages linking to zope.org (compare php.net:12,000 ; :: apache.org:60,000). Why? :: :: If nobody does anything, this will take time to change. If we want this to :: change faster, all of us have to actively market Zope. This involves talking :: about in appropriate newsgrousps, putting up zope webpages, :: making Zope easier to learn and use, adding flashy features etc. :: All this can make a whole lot of difference. Yesterday, I was asked, by a client, to put together a side-by-side comparison of Zope and Vignette for presentation to their IT managers. I did a lot of searching on the Web, but found only the one article from this list last October, which was written by someone with no experience with either of the two! Frequently, people have asked for this sort of data on this list, but I've never seen a coherent answer. It's a FAQ. Digital Creations might be able to help here, since they have direct experience with clients who have started with Vignette and switched to Zope. It would probably be "impolitic" for DC to author a public article taking Vignette to task, but certainly they could help an independent author with facts. If that article could then be published in DevShed or Web Development, or another visible place, it would give us all something to point to. Search engines would index it. The word would spread. Vignette is often characterized as the "industrial strength" CMS, so it would seem a good target for a comparison, especially due to its high cost.
I have started a list of Pro-Zope Material here.. http://www.zope.org/Members/BwanaZulia/zope.html I am hoping to add some performance benchmarks, quotes, etc... In other words a good place to get that information that you need to submit to the client. I would like to see something like this done on a better (bigger scale) as part of the DC marketing, but this is a start. Any suggestions, links, comments would be great... JMA
From: Patrick Phalen <zope@teleo.net> Organization: TeleoNet Date: Wed, 8 Mar 2000 08:50:32 -0800 To: zope@zope.org Cc: paul@digicool.com Subject: Re: [Zope] Zope needs this (and Dynamo has it)
[Shalabh Chaturvedi, on Wed, 08 Mar 2000]
:: I see a number of articles/sites about 'app servers' which don't mention Zope :: but mention others (including some mickey mouse servers I've never heard of). :: Eg: http://serverwatch.internet.com/appservers.html :: Why? Maybe Zope isn't talked about at all outside some circles? :: :: Altavista shows about 1058 pages linking to zope.org (compare php.net:12,000 ; :: apache.org:60,000). Why? :: :: If nobody does anything, this will take time to change. If we want this to :: change faster, all of us have to actively market Zope. This involves talking :: about in appropriate newsgrousps, putting up zope webpages, :: making Zope easier to learn and use, adding flashy features etc. :: All this can make a whole lot of difference.
Yesterday, I was asked, by a client, to put together a side-by-side comparison of Zope and Vignette for presentation to their IT managers. I did a lot of searching on the Web, but found only the one article from this list last October, which was written by someone with no experience with either of the two!
Frequently, people have asked for this sort of data on this list, but I've never seen a coherent answer. It's a FAQ.
Digital Creations might be able to help here, since they have direct experience with clients who have started with Vignette and switched to Zope. It would probably be "impolitic" for DC to author a public article taking Vignette to task, but certainly they could help an independent author with facts. If that article could then be published in DevShed or Web Development, or another visible place, it would give us all something to point to. Search engines would index it. The word would spread.
Vignette is often characterized as the "industrial strength" CMS, so it would seem a good target for a comparison, especially due to its high cost.
_______________________________________________ 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 )
PCWeek did a shoot-out of various CMS packages about six months ago. They created a "scoresheet" that might be useful. Unfortunately, Vignette stood by their policy of not allowing their software to reviewed, so it includes several other CMS packages. --Paul Patrick Phalen wrote:
[Shalabh Chaturvedi, on Wed, 08 Mar 2000]
:: I see a number of articles/sites about 'app servers' which don't mention Zope :: but mention others (including some mickey mouse servers I've never heard of). :: Eg: http://serverwatch.internet.com/appservers.html :: Why? Maybe Zope isn't talked about at all outside some circles? :: :: Altavista shows about 1058 pages linking to zope.org (compare php.net:12,000 ; :: apache.org:60,000). Why? :: :: If nobody does anything, this will take time to change. If we want this to :: change faster, all of us have to actively market Zope. This involves talking :: about in appropriate newsgrousps, putting up zope webpages, :: making Zope easier to learn and use, adding flashy features etc. :: All this can make a whole lot of difference.
Yesterday, I was asked, by a client, to put together a side-by-side comparison of Zope and Vignette for presentation to their IT managers. I did a lot of searching on the Web, but found only the one article from this list last October, which was written by someone with no experience with either of the two!
Frequently, people have asked for this sort of data on this list, but I've never seen a coherent answer. It's a FAQ.
Digital Creations might be able to help here, since they have direct experience with clients who have started with Vignette and switched to Zope. It would probably be "impolitic" for DC to author a public article taking Vignette to task, but certainly they could help an independent author with facts. If that article could then be published in DevShed or Web Development, or another visible place, it would give us all something to point to. Search engines would index it. The word would spread.
Vignette is often characterized as the "industrial strength" CMS, so it would seem a good target for a comparison, especially due to its high cost.
On Thu, Mar 09, 2000 at 07:31:07AM -0500, Paul Everitt wrote:
PCWeek did a shoot-out of various CMS packages about six months ago. They created a "scoresheet" that might be useful. Unfortunately, Vignette stood by their policy of not allowing their software to reviewed, so it includes several other CMS packages.
Can they do that? How? Something funny in the license agreement? -- Stephen Pitts smpitts@midsouth.rr.com
At 14:47 07/03/00 -0600, you wrote:
Alexander Staubo <alex@mop.no> writes:
[snipped]
Zope doesn't have the flashy packaging and sexiness of a product line Dynamo -- which, actually, I strongly urge you (and everybody else in this forum) to experience yourself, before you snap back at my again -- and this affects management decisions. Dynamo is exceedingly sexy, and it boasts the kind of bullshit magic that have management and tech people alike drooling.
OK, but see you're trying to make Linux something it is not. Linux is not about marketing. It is not about world domination. We specifically do not care about this :-)
I would say that I specifically do care about this. As a freelance developer I want there to be good recognition of Zope in the market place. It is all about recognition. I was extolling the virtues of Zope to the IT Director at a client and he said 'So why haven't I heard of Zope ?'. My answer, that it was all very new and on the verge of success probably did not convince him. (Of course it is all very new and it is on the verge of success ). If I say Linux, Perl or C then management are usually quite happy. These are recognised names - but nobody owns them. SO it is possible for free software to be successful in the sense that they are as well recognised as commercial products (which have huge budgets behind them). Some management (perhaps most) will prefer to buy a "fully supported" product from a major player. We don't need to take on that kind of marketing head on. Rather we can present Zope and Python as tools to do a job, not strategic decisions to be made by management. However it is reasonable for management to ask "Will Zope be around in three years" - "can we de-Zope if we have to" - "Who owns Zope" "Who uses Zope". Managers are not likely to take a "risk" on a product. At the moment they usually feel happy that Linux, C and Perl are going to be around in three years time. If Zope is to succeed it will be because of its capabilities as a product - because it installs out of the box in six minutes, while the Microsoft equivalent takes 5 hours. Because 60 minutes after downloading it you can be running a web page which interrogates your legacy databases (which is what happened to me). We know about the documentation issue, which is hopefully being sorted. I feel there is also an issue with the product itself. Zope seems to work on two levels - you have a very high-level part - I'm thinking of the security model, the SQL methods and the Z Search interface, the drop-in products like SquishDot etc. These set Zope apart from other technologies which people might use (PHP/ASP etc). You also have a low-level part (External methods etc). Because Zope has the high level part it encourages the thought that there is not much 'programming' needed to develop a Zope site. But sooner or later you are going to hit a wall - for example questions you see asked on this list such as "how do I assign a value to a variable". Well the answer is ... <dtml-call expr="REQUEST.set('abc_search', strip_abc(abc_text))"> ... a string of gobbledygook. (So what does the dtml-let tag do is the obvious question that springs to mind.) It is great that Zope has the low level stuff but I feel that work needs to be done 1) To analyse actual usage of Zope to see what features are being used and which areas of usage cause concern/difficulty 2) To Implement high level dtml tags to implement them. I've stuck my neck out here - feel free to chop it off. Richard Moon richard@dcs.co.uk
Richard Moon wrote: [snip discussion why marketing is important]
I feel there is also an issue with the product itself. Zope seems to work on two levels - you have a very high-level part - I'm thinking of the security model, the SQL methods and the Z Search interface, the drop-in products like SquishDot etc. These set Zope apart from other technologies which people might use (PHP/ASP etc).
You also have a low-level part (External methods etc). Because Zope has the high level part it encourages the thought that there is not much 'programming' needed to develop a Zope site. But sooner or later you are going to hit a wall - for example questions you see asked on this list such as "how do I assign a value to a variable". Well the answer is ...
<dtml-call expr="REQUEST.set('abc_search', strip_abc(abc_text))">
... a string of gobbledygook. (So what does the dtml-let tag do is the obvious question that springs to mind.)
If you have a programmer and a web designer around it's possible to seperate the two tasks quite well, though, in my experience. Likewise a situation with a programmer and a content manager, which is the situation I'm in right now. Still, both the web designer and the content manager want to know more about Zope, and this does throw them off into the deep end (Python, DTML, object oriented programming, etc).
It is great that Zope has the low level stuff but I feel that work needs to be done
1) To analyse actual usage of Zope to see what features are being used and which areas of usage cause concern/difficulty 2) To Implement high level dtml tags to implement them.
I've stuck my neck out here - feel free to chop it off.
I won't chop it off; you're right. Though I would say a simpler DTML is only half of the story; the other half of the story is already there -- people _can_ use drop-in components. It's just that we need more and better drop-in components (with possibly a nicer interface, ala Zope PTK and/or Zope Mozilla). Still, a simple variety of DTML would be nice. Currently you can successfully use a subset of DTML, which almost has no arcaneness but is still very powerful. PythonMethods will help even more there. Still, DTML allows too much, so it's too easy to move into the arcane domain. Also some of its powerful features have the side effect that some of the simple features look too complex. So perhaps we should create a seperate language, based on the subset, with simplified syntax, which _doesn't_ allow fancy stuff. The fancy stuff would be in DTML-methods or PythonMethods of some kind. Perhaps even the HTML would be in seperate methods. Perhaps some XML-ish Zope glue language, like this: <zopeglue> <var object="header"/> <assign name="age" object="get_age"/> <var object="show_age_intro" arguments="age"/> <var object="layout.table_header"/> <in object="get_above_age" arguments="age"> <var object="myrecord" arguments="in_item"/> </in> <var object="layout.table_footer"/> <assign name="age" object="getage"> <var object="footer"/> </zopeglue> And then some IDE that allows you to easily create all objects you refer to here. Perhaps something wiki-like; any object name that you refer to in the glue that can't be found will be presented in a list after you edit the glue, and you can create objects for it then. Ideas, ideas, now for some time. :) Regards, Martijn
At 17:01 08/03/00 +0100, you wrote:
If you have a programmer and a web designer around it's possible to seperate the two tasks quite well, though, in my experience. Likewise a situation with a programmer and a content manager, which is the situation I'm in right now.
Me too - only trouble is I'm the programmer. I'm struggling and I can't afford to retire just yet :-)
Still, both the web designer and the content manager want to know more about Zope, and this does throw them off into the deep end (Python, DTML, object oriented programming, etc).
It is great that Zope has the low level stuff but I feel that work needs to be done
1) To analyse actual usage of Zope to see what features are being used and which areas of usage cause concern/difficulty 2) To Implement high level dtml tags to implement them.
I've stuck my neck out here - feel free to chop it off.
I won't chop it off; you're right. Though I would say a simpler DTML is only half of the story; the other half of the story is already there -- people _can_ use drop-in components. It's just that we need more and better drop-in components (with possibly a nicer interface, ala Zope PTK and/or Zope Mozilla).
I am impressed with the products I've seen so far but they can always be improved and there's certainly room for more. Perhaps there should be a coordinated 'wish list' on zope.org so that developers can pick up on needed products, or collaborate on enhancements of existing products ?
Still, a simple variety of DTML would be nice. Currently you can successfully use a subset of DTML, which almost has no arcaneness but is still very powerful.
Agreed <dml-var object> is a pretty good start for most people.
PythonMethods will help even more there. Still, DTML allows too much, so it's too easy to move into the arcane domain. Also some of its powerful features have the side effect that some of the simple features look too complex.
So perhaps we should create a seperate language, based on the subset, with simplified syntax, which _doesn't_ allow fancy stuff. The fancy stuff would be in DTML-methods or PythonMethods of some kind. Perhaps even the HTML would be in seperate methods. Perhaps some XML-ish Zope glue language, like this:
<zopeglue> <var object="header"/>
<assign name="age" object="get_age"/> <var object="show_age_intro" arguments="age"/>
<var object="layout.table_header"/> <in object="get_above_age" arguments="age"> <var object="myrecord" arguments="in_item"/> </in> <var object="layout.table_footer"/>
<assign name="age" object="getage"> <var object="footer"/> </zopeglue>
Well that's a bit further than I was proposing. Perhaps I would settle for dtml which accessed the REQUEST object more simply. However your syntax looks good.
And then some IDE that allows you to easily create all objects you refer to here.
And browse all the objects and all the methods and attributes defined on them.
Perhaps something wiki-like; any object name that you refer to in the glue that can't be found will be presented in a list after you edit the glue, and you can create objects for it then.
Ideas, ideas, now for some time. :)
Regards,
Martijn
_______________________________________________ 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 )
Richard Moon richard@dcs.co.uk
Martijn Faassen wrote:
Still, a simple variety of DTML would be nice. Currently you can successfully use a subset of DTML, which almost has no arcaneness but is still very powerful. PythonMethods will help even more there. Still, DTML allows too much, so it's too easy to move into the arcane domain. Also some of its powerful features have the side effect that some of the simple features look too complex.
So perhaps we should create a seperate language, based on the subset, with simplified syntax, which _doesn't_ allow fancy stuff. The fancy stuff would be in DTML-methods or PythonMethods of some kind. Perhaps even the HTML would be in seperate methods. Perhaps some XML-ish Zope glue language, like this:
<zopeglue> <var object="header"/>
<assign name="age" object="get_age"/> <var object="show_age_intro" arguments="age"/>
<var object="layout.table_header"/> <in object="get_above_age" arguments="age"> <var object="myrecord" arguments="in_item"/> </in> <var object="layout.table_footer"/>
<assign name="age" object="getage"> <var object="footer"/> </zopeglue>
I don't think a new syntax should be brought about. There are too many things to learn already, it will only add to the confusion. I do agree that dtml is complex and something needs to be done about it. Probably a subset of the current dtml itself - with minimal additions which make somethings easy - would be good. Also (if this is seriously being considered) I would favour for a somewhat different paradigm: Instead of:
<var object="layout.table_header"/> <in object="get_above_age" arguments="age"> <var object="myrecord" arguments="in_item"/> </in> <var object="layout.table_footer"/>
We could have: <dtml-var object="layout.table"> <param name="datasource" value="get_above_age"> <param name="columns" value="Name,Age"> </dtml-var> The advantage here is that: o One logical presentation element (a table) is one element in dtml code. o One-to-one relation is possible between the code and any GUI entity being used to design (think ZStudio). This means the layout.table can be one icon that is dropped into a design view and it's parameters specifed through some fancy widget. Also when the code is stored and reloaded, it would still be possible to display the same GUI entity in the design view and it's parameters would be editable. Discussions on the above have taken place on the ptk and zope-moz lists. Regards, Shalabh ______________________________ Shalabh Chaturvedi icq://43284067 http://advogato.org/person/shalabh/
Shalabh Chaturvedi wrote:
Martijn Faassen wrote:
Still, a simple variety of DTML would be nice. Currently you can successfully use a subset of DTML, which almost has no arcaneness but is still very powerful. PythonMethods will help even more there. Still, DTML allows too much, so it's too easy to move into the arcane domain. Also some of its powerful features have the side effect that some of the simple features look too complex. [snip new language] I don't think a new syntax should be brought about. There are too many things to learn already, it will only add to the confusion.
That's true, but that shouldn't hold us back indefinitely; some things are can only be improved after a while if they're redesigned from scratch, otherwise the back-compatibility issues become too complicated. I don't know if DTML is at this state though, and any new language proposal should be something to consider for the (very) long term.
I do agree that dtml is complex and something needs to be done about it. Probably a subset of the current dtml itself - with minimal additions which make somethings easy - would be good.
Also (if this is seriously being considered)
I don't think anyone's serious yet. :)
I would favour for a somewhat different paradigm:
Instead of:
<var object="layout.table_header"/> <in object="get_above_age" arguments="age"> <var object="myrecord" arguments="in_item"/> </in> <var object="layout.table_footer"/>
We could have: <dtml-var object="layout.table"> <param name="datasource" value="get_above_age"> <param name="columns" value="Name,Age"> </dtml-var>
The advantage here is that: o One logical presentation element (a table) is one element in dtml code.
But you lose some flexibility in defining table headers and footers; you have to be careful your simple language becomes too rigid, making too many assumptions.
o One-to-one relation is possible between the code and any GUI entity being used to design (think ZStudio). This means the layout.table can be one icon that is dropped into a design view and it's parameters specifed through some fancy widget. Also when the code is stored and reloaded, it would still be possible to display the same GUI entity in the design view and it's parameters would be editable.
Hm, what you're proposing is some higher level object (a product) that does tables (in this case). That would in fact be rather neat.. Our simple glue language could become extremely simple if we have sufficient higher level components, and if it's easy enough to code up your own components. I'm doing something like that for web forms in my ZFormulator product.
Discussions on the above have taken place on the ptk and zope-moz lists.
Okay, this kind of discussion probably belongs on another list, I agree. :) Regards, Martijn
Martijn Faassen wrote:
Shalabh Chaturvedi wrote:
I don't think a new syntax should be brought about. There are too many things to learn already, it will only add to the confusion.
That's true, but that shouldn't hold us back indefinitely; some things are can only be improved after a while if they're redesigned from scratch, otherwise the back-compatibility issues become too complicated. I don't know if DTML is at this state though, and any new language proposal should be something to consider for the (very) long term.
If we can gather enough support for something like this, I'm all for it.
I would favour for a somewhat different paradigm: [ paradigm snipped ]
The advantage here is that: o One logical presentation element (a table) is one element in dtml code.
But you lose some flexibility in defining table headers and footers; you have to be careful your simple language becomes too rigid, making too many assumptions.
Um, no. Since the code that defines 'layout.table' is also available and editable, (just like any other object). So you can not only code the specific header you want into the object, but also create a parameter which can be used like so: <dtml-var object="layout.table"> <param name="datasource" value="get_above_age"> <param name="columns" value="Name,Age"> <param name="table_tagattrs" value=" border=0 bgcolor=green"> </dtml-var>
o One-to-one relation is possible between the code and any GUI entity
Hm, what you're proposing is some higher level object (a product) that does tables (in this case). That would in fact be rather neat.. Our simple glue language could become extremely simple if we have sufficient higher level components, and if it's easy enough to code up your own components. I'm doing something like that for web forms in my ZFormulator product.
I learnt you're doing something similar (from Rik). I have to look at it. What I'm suggesting is that instead of having to create a product every time you want a higher level object, we could have a framework so that you could just create an object that does it. The goal would be to make it easy for everyone to code their own component objects (or templates, or patterns, or whatever) Another thing I would like is that people start looking at 'documents' differently. Instead of 'my_element_header' and 'my_element_footer', people think of 'my_element' which takes one or more parameters. (Please don't flame me, it's Paul who started all this :-) PTK List thread: http://lists.zope.org/pipermail/zope-ptk/2000-February/000347.html Zope-Moz List Thread: http://lists.zope.org/pipermail/zope-mozilla/2000-February/000125.html Cheers, Shalabh ______________________________ Shalabh Chaturvedi icq://43284067 http://advogato.org/person/shalabh/
participants (8)
-
J. Atwood -
John Goerzen -
Martijn Faassen -
Patrick Phalen -
Paul Everitt -
Richard Moon -
Shalabh Chaturvedi -
Stephen Pitts