Slashdot Mirror

There's Zope, which has a number of projects to put courses online. I have considered using ZQuest. It is easy to use and easy to administer. Moreover, once it is installed, it is fairly easy to deal with "teacher" accounts (so that other teachers can publish their stuff). It's easy to use for the end user as well, and can be translated into a number of languages out of the box. There's a demo website for ZQuest.

Web site design needs a lot of different things, Information architecture & usability, HTML & XHTML, CSS & implementation bugs, search engine ideas and keyword research, Web server techniques & content management, deeziner discussion & tech discussion, good practices & sucky practices.

I could go on. My point is that you can either be a half-hearted jack-of-all-trades, or do the Web a favour and pick something, learn to understand it and collaborate with people who have complimentary skills.

Of course a Web site is no use if no one visits it. A link from the /. home page is a good start.

Calum

I hate how corporations feel like they get to dictate when things as global as the internet need to change just because they want to. Let the people catch up to the langauges. I am just learning Perl, my first programming language, and MS already has 2 new languages that are supposed to be the norm for the Net.

s/Microsoft/Greedy-Mongrosoft/g

Zope scales very well. Your option is to use the ZEO Zope Enterprise Options which is a high level, multi-OS clustering ability. It runs just fine on www.CBSNewYork.com which is running on 48 dual processor linux boxes.

You might appreciate Zope and Cocoon: A Comparative Review. It is a fairly accurate comparison, but perhaps a bit harsh on the issue of Zope's "Integration with Source Code Control System". We do most of our Zope development in Python - on the file system - and use CVS for version control. For non-filesystem code, there is a product called ZCVSMixin which looks promising, but we don't have any experience with it.

It's not a matter of what it can't do, it's a matter of how it is done. Zope helps me (the solo programmer) by enforceing separation of presentation and logic. It would also be good for teams where duties are split between content, design, and logic.

About a week ago I started a new web project using python scripts for its cgi. I wasn't spending a lot of time writing the business logic because I was spending a lot of time writing the code that displays HTML.

Now, I'm a one-man operation, not a professional programmer, and also a pathetically poor coder, so progress was painful and slow.

I investigated Zope and discovered that someone else had done the boring part and made a pretty robust platform for me to develop my application.

After a brief intermission where I read the on-line Zope Book, called strangely enough "The Zope Book" I managed to get my ideas working.

It's a benefit for me, because I can write smaller, more modular logic code (which I might actually get right), and I don't have to worry about writing a bunch of HTML-generating code that (a) would be boring, and (b) would be buggy.

Teams will be able to use Zope effectively too, since you can separate logic, design, and content and enforce it by only giving certain users access to their parts.

Zope is a server, and the files and directory you store data in is not part of the regular filesystem. I have some problems with the web interface, especially over the Internet, but most of my concerns go away when I run it on the localhost. You can ftp to the server using emacs and edit the files remotely in the usual way.

Also, I find that the documentation is pretty good, but they are in desperate need of a Zope Cookbook.

Yeah, yeah, yeah... Here's some Python links for you:

The official site. Downloads & Tutorials
An article by ESR praising python
A couple small intros to Python
An interesting look at Python from a LISPers point of view
Zope, Python-based web application server platfrom
Pygame : A Python interface to the SDL game library

I can't believe no one has mentioned Structured Text yet. It's really simple (you only have to learn a few simple rules of editing plain text ASCII files to express structure) and pretty intuitive (it's like Python in the sense that your indentation expresses your structure). You can convert it to decent looking html with existing scripts (that come with zope). You can convert this generated html into .pdf automatically using the GPL htmldoc program . And the Zope book was written in Structured Text, to prove that it scales.

• Name The Register's bird!
  
• Name Zope's Z-on-a-sphere!
  
• Name ZD-Net's slightly rotated red rectangle!
  
• Name Slashdot's rounded green corner!
  

Yesterday evening, after I read about the new iMac and in particular iPhoto, I showed the new stuff to my wife, carefully guiding here to agree that we might buy one of these slim new machines. We already own a PBG4, an older PPC 96000 apart from Wintel machines running W98 or Suse Linux. So far, my wife hesitated to touch the Macs since she feels technologically challenged (like many people) and is happy working with M$ Word and Internet Explorer on the PC.

I tried to argue how easily she could herself create digital albums of our 5-month old son, or create video clips using iMovie together with a digital videocamera (to be bought too). So far, I've been afraid to ask her to handle the publishing process starting with importing the JPEGS from our memory card, using Photoshop to edit the image (e.g., eliminate red eye effect), crop or resize the images, and finally print or publish the images.

Without boring you, the bottom line of my message is: attracted by the excellent hardware and software design of the new iMac, my wife got really enthusiastic about learning how to manage digital content with iPhoto and perhaps iMovie. I am very glad about that fact because this frees me from publishing and printing every single photo on my own, a spend more time on building up the homepage of Jannik and learing Zope or OpenACS.

There's a nice book about Zope, available in print and online.

There's a nice book about Zope, available in print and online.

http://www.zope.org

ParsedXML

http://www.zope.org

ParsedXML

• Object A is a Object B
• Object A Has a/many Object B(s)

We shipped the final version of ScriptX, and Kaleida closed in January of 1996. Apple said they were going to support it at first, then swept it under the rug. Now you can't find anything about ScriptX on Apple's or IBM's web sites.

Python and Zope are clearly the coolest dynamic cross platform open source programming environments happening today.

-Don

Separation of content, logic, and presentation is very difficult to do in current web-app developments environments.

The breakdown is not on the logic/content side of the equation, or the presentation/content side, but mainly in the presentation/logic arena.

Imagine an HTML designer who has mocked up a page for a web-app, and hands it off to the dev team for them to add in the neccessary laogic to dynamically include the user-name, current balance, contents of the shopping cart, etc. Depending on the exact paragdigm taht their tools use, they will either:

a) Chop up the page and include various fragments in the programs that are designed to emit said fragments at the opportune times to be assembled into a text stream eventually recived by a browser

or b) Various bits of logic get stuck into the page in oder to parameterize and/or conditionalize it, using either some sort of speacial tagging format or actual inlined blocks of code.

Whichever approach the dev team's tools use, the result is the same: the designer can no longer change the altered page.

Even in case b), which maintains some semblance of a coherent 'page', the designer cannot load the page-with-logic into their favorite visual editor and see anything resembling the actual page. They certainly can't edit it to change the look-and-feel without breaking the carefully constructed logic.

The end result is that the designer has no recourse other than to take their page design, change it, and hand it over to the dev-team again for them to re-include (in some cases re-code) all of their logic.

This is obviously a very wasteful approach.

Amazingly, there actually is a solution to this problem. It's called Template Attribute Language (TAL), and it solves the problem by adding programming directives to the page via XHTML attributes on the existing tags. The language is deliberately designed to only be suitable for presentation logic, relegating business logic code to some other objects, where the designer can't see them. This helps enforce the appropriate distinction between presentation logic and business logic that most current development environments ignore, thus encouraging their admixture.

Currently, TAL (and the related specifications TALES and METAL) are only implemented in one environment, but the language has been deliberately designed to be as platform agnostic as possible. Other implementations of the specification are possible, and even desireable.

Articles:

Zope Page Templates: Getting Started

Zope Page Templates: Advanced Usage

Using Zope with Amaya, Dreamweaver, and other WYSIWYG Tools

Separation of content, logic, and presentation is very difficult to do in current web-app developments environments.

The breakdown is not on the logic/content side of the equation, or the presentation/content side, but mainly in the presentation/logic arena.

Imagine an HTML designer who has mocked up a page for a web-app, and hands it off to the dev team for them to add in the neccessary laogic to dynamically include the user-name, current balance, contents of the shopping cart, etc. Depending on the exact paragdigm taht their tools use, they will either:

a) Chop up the page and include various fragments in the programs that are designed to emit said fragments at the opportune times to be assembled into a text stream eventually recived by a browser

or b) Various bits of logic get stuck into the page in oder to parameterize and/or conditionalize it, using either some sort of speacial tagging format or actual inlined blocks of code.

Whichever approach the dev team's tools use, the result is the same: the designer can no longer change the altered page.

Even in case b), which maintains some semblance of a coherent 'page', the designer cannot load the page-with-logic into their favorite visual editor and see anything resembling the actual page. They certainly can't edit it to change the look-and-feel without breaking the carefully constructed logic.

The end result is that the designer has no recourse other than to take their page design, change it, and hand it over to the dev-team again for them to re-include (in some cases re-code) all of their logic.

This is obviously a very wasteful approach.

Amazingly, there actually is a solution to this problem. It's called Template Attribute Language (TAL), and it solves the problem by adding programming directives to the page via XHTML attributes on the existing tags. The language is deliberately designed to only be suitable for presentation logic, relegating business logic code to some other objects, where the designer can't see them. This helps enforce the appropriate distinction between presentation logic and business logic that most current development environments ignore, thus encouraging their admixture.

Currently, TAL (and the related specifications TALES and METAL) are only implemented in one environment, but the language has been deliberately designed to be as platform agnostic as possible. Other implementations of the specification are possible, and even desireable.

Articles:

Zope Page Templates: Getting Started

Zope Page Templates: Advanced Usage

Using Zope with Amaya, Dreamweaver, and other WYSIWYG Tools

Separation of content, logic, and presentation is very difficult to do in current web-app developments environments.

The breakdown is not on the logic/content side of the equation, or the presentation/content side, but mainly in the presentation/logic arena.

Imagine an HTML designer who has mocked up a page for a web-app, and hands it off to the dev team for them to add in the neccessary laogic to dynamically include the user-name, current balance, contents of the shopping cart, etc. Depending on the exact paragdigm taht their tools use, they will either:

a) Chop up the page and include various fragments in the programs that are designed to emit said fragments at the opportune times to be assembled into a text stream eventually recived by a browser

or b) Various bits of logic get stuck into the page in oder to parameterize and/or conditionalize it, using either some sort of speacial tagging format or actual inlined blocks of code.

Whichever approach the dev team's tools use, the result is the same: the designer can no longer change the altered page.

Even in case b), which maintains some semblance of a coherent 'page', the designer cannot load the page-with-logic into their favorite visual editor and see anything resembling the actual page. They certainly can't edit it to change the look-and-feel without breaking the carefully constructed logic.

The end result is that the designer has no recourse other than to take their page design, change it, and hand it over to the dev-team again for them to re-include (in some cases re-code) all of their logic.

This is obviously a very wasteful approach.

Amazingly, there actually is a solution to this problem. It's called Template Attribute Language (TAL), and it solves the problem by adding programming directives to the page via XHTML attributes on the existing tags. The language is deliberately designed to only be suitable for presentation logic, relegating business logic code to some other objects, where the designer can't see them. This helps enforce the appropriate distinction between presentation logic and business logic that most current development environments ignore, thus encouraging their admixture.

Currently, TAL (and the related specifications TALES and METAL) are only implemented in one environment, but the language has been deliberately designed to be as platform agnostic as possible. Other implementations of the specification are possible, and even desireable.

Articles:

Zope Page Templates: Getting Started

Zope Page Templates: Advanced Usage

Using Zope with Amaya, Dreamweaver, and other WYSIWYG Tools

Separation of content, logic, and presentation is very difficult to do in current web-app developments environments.

The breakdown is not on the logic/content side of the equation, or the presentation/content side, but mainly in the presentation/logic arena.

Imagine an HTML designer who has mocked up a page for a web-app, and hands it off to the dev team for them to add in the neccessary laogic to dynamically include the user-name, current balance, contents of the shopping cart, etc. Depending on the exact paragdigm taht their tools use, they will either:

a) Chop up the page and include various fragments in the programs that are designed to emit said fragments at the opportune times to be assembled into a text stream eventually recived by a browser

or b) Various bits of logic get stuck into the page in oder to parameterize and/or conditionalize it, using either some sort of speacial tagging format or actual inlined blocks of code.

Whichever approach the dev team's tools use, the result is the same: the designer can no longer change the altered page.

Even in case b), which maintains some semblance of a coherent 'page', the designer cannot load the page-with-logic into their favorite visual editor and see anything resembling the actual page. They certainly can't edit it to change the look-and-feel without breaking the carefully constructed logic.

The end result is that the designer has no recourse other than to take their page design, change it, and hand it over to the dev-team again for them to re-include (in some cases re-code) all of their logic.

This is obviously a very wasteful approach.

Amazingly, there actually is a solution to this problem. It's called Template Attribute Language (TAL), and it solves the problem by adding programming directives to the page via XHTML attributes on the existing tags. The language is deliberately designed to only be suitable for presentation logic, relegating business logic code to some other objects, where the designer can't see them. This helps enforce the appropriate distinction between presentation logic and business logic that most current development environments ignore, thus encouraging their admixture.

Currently, TAL (and the related specifications TALES and METAL) are only implemented in one environment, but the language has been deliberately designed to be as platform agnostic as possible. Other implementations of the specification are possible, and even desireable.

Articles:

Zope Page Templates: Getting Started

Zope Page Templates: Advanced Usage

Using Zope with Amaya, Dreamweaver, and other WYSIWYG Tools

Separation of content, logic, and presentation is very difficult to do in current web-app developments environments.

The breakdown is not on the logic/content side of the equation, or the presentation/content side, but mainly in the presentation/logic arena.

Imagine an HTML designer who has mocked up a page for a web-app, and hands it off to the dev team for them to add in the neccessary laogic to dynamically include the user-name, current balance, contents of the shopping cart, etc. Depending on the exact paragdigm taht their tools use, they will either:

a) Chop up the page and include various fragments in the programs that are designed to emit said fragments at the opportune times to be assembled into a text stream eventually recived by a browser

or b) Various bits of logic get stuck into the page in oder to parameterize and/or conditionalize it, using either some sort of speacial tagging format or actual inlined blocks of code.

Whichever approach the dev team's tools use, the result is the same: the designer can no longer change the altered page.

Even in case b), which maintains some semblance of a coherent 'page', the designer cannot load the page-with-logic into their favorite visual editor and see anything resembling the actual page. They certainly can't edit it to change the look-and-feel without breaking the carefully constructed logic.

The end result is that the designer has no recourse other than to take their page design, change it, and hand it over to the dev-team again for them to re-include (in some cases re-code) all of their logic.

This is obviously a very wasteful approach.

Amazingly, there actually is a solution to this problem. It's called Template Attribute Language (TAL), and it solves the problem by adding programming directives to the page via XHTML attributes on the existing tags. The language is deliberately designed to only be suitable for presentation logic, relegating business logic code to some other objects, where the designer can't see them. This helps enforce the appropriate distinction between presentation logic and business logic that most current development environments ignore, thus encouraging their admixture.

Currently, TAL (and the related specifications TALES and METAL) are only implemented in one environment, but the language has been deliberately designed to be as platform agnostic as possible. Other implementations of the specification are possible, and even desireable.

Articles:

Zope Page Templates: Getting Started

Zope Page Templates: Advanced Usage

Using Zope with Amaya, Dreamweaver, and other WYSIWYG Tools

Separation of content, logic, and presentation is very difficult to do in current web-app developments environments.

The breakdown is not on the logic/content side of the equation, or the presentation/content side, but mainly in the presentation/logic arena.

Imagine an HTML designer who has mocked up a page for a web-app, and hands it off to the dev team for them to add in the neccessary laogic to dynamically include the user-name, current balance, contents of the shopping cart, etc. Depending on the exact paragdigm taht their tools use, they will either:

a) Chop up the page and include various fragments in the programs that are designed to emit said fragments at the opportune times to be assembled into a text stream eventually recived by a browser

or b) Various bits of logic get stuck into the page in oder to parameterize and/or conditionalize it, using either some sort of speacial tagging format or actual inlined blocks of code.

Whichever approach the dev team's tools use, the result is the same: the designer can no longer change the altered page.

Even in case b), which maintains some semblance of a coherent 'page', the designer cannot load the page-with-logic into their favorite visual editor and see anything resembling the actual page. They certainly can't edit it to change the look-and-feel without breaking the carefully constructed logic.

The end result is that the designer has no recourse other than to take their page design, change it, and hand it over to the dev-team again for them to re-include (in some cases re-code) all of their logic.

This is obviously a very wasteful approach.

Amazingly, there actually is a solution to this problem. It's called Template Attribute Language (TAL), and it solves the problem by adding programming directives to the page via XHTML attributes on the existing tags. The language is deliberately designed to only be suitable for presentation logic, relegating business logic code to some other objects, where the designer can't see them. This helps enforce the appropriate distinction between presentation logic and business logic that most current development environments ignore, thus encouraging their admixture.

Currently, TAL (and the related specifications TALES and METAL) are only implemented in one environment, but the language has been deliberately designed to be as platform agnostic as possible. Other implementations of the specification are possible, and even desireable.

Articles:

Zope Page Templates: Getting Started

Zope Page Templates: Advanced Usage

Using Zope with Amaya, Dreamweaver, and other WYSIWYG Tools

Separation of content, logic, and presentation is very difficult to do in current web-app developments environments.

The breakdown is not on the logic/content side of the equation, or the presentation/content side, but mainly in the presentation/logic arena.

Imagine an HTML designer who has mocked up a page for a web-app, and hands it off to the dev team for them to add in the neccessary laogic to dynamically include the user-name, current balance, contents of the shopping cart, etc. Depending on the exact paragdigm taht their tools use, they will either:

a) Chop up the page and include various fragments in the programs that are designed to emit said fragments at the opportune times to be assembled into a text stream eventually recived by a browser

or b) Various bits of logic get stuck into the page in oder to parameterize and/or conditionalize it, using either some sort of speacial tagging format or actual inlined blocks of code.

Whichever approach the dev team's tools use, the result is the same: the designer can no longer change the altered page.

Even in case b), which maintains some semblance of a coherent 'page', the designer cannot load the page-with-logic into their favorite visual editor and see anything resembling the actual page. They certainly can't edit it to change the look-and-feel without breaking the carefully constructed logic.

The end result is that the designer has no recourse other than to take their page design, change it, and hand it over to the dev-team again for them to re-include (in some cases re-code) all of their logic.

This is obviously a very wasteful approach.

Amazingly, there actually is a solution to this problem. It's called Template Attribute Language (TAL), and it solves the problem by adding programming directives to the page via XHTML attributes on the existing tags. The language is deliberately designed to only be suitable for presentation logic, relegating business logic code to some other objects, where the designer can't see them. This helps enforce the appropriate distinction between presentation logic and business logic that most current development environments ignore, thus encouraging their admixture.

Currently, TAL (and the related specifications TALES and METAL) are only implemented in one environment, but the language has been deliberately designed to be as platform agnostic as possible. Other implementations of the specification are possible, and even desireable.

Articles:

Zope Page Templates: Getting Started

Zope Page Templates: Advanced Usage

Using Zope with Amaya, Dreamweaver, and other WYSIWYG Tools

Since Zope does everything that .NET reportedly does, and has been doing so longer, who cares?

Those of us who use Zope are feeling much better than the Enhydra crowd these days. We've know for years that the rug would one day come out from underneath them just like it did with the Ars Digita community.

Zope Corporation has been moving in the complete oposite direction as Lutris and AD. They've recently opened their CVS to community check-ins, and are working with RMS to make their already open-source license GPL compatable.

When Zope Corporation hired the PythonLabs team, they heartily agreed to turn over the copyright of Python to Guido van Rossum personally, to be later transfered to the a community led Python Software Foundation a non-profit organization whose members consist of all of the developers who have CVS check-in ability.

It's obvious (to me, at least) that you can't build a sucessful open-source application based on a closed source platform like Java. Sooner or later, the virus of commercialism will invade the mindset of all the layers above it. Immagine if Apache, or Emacs were written in a closed source language. They would not be what they are today.

So, hopefully all those folks will learn their lesson and switch to a real open source object-oriented web application platform like Zope.

Those of us who use Zope are feeling much better than the Enhydra crowd these days. We've know for years that the rug would one day come out from underneath them just like it did with the Ars Digita community.

Zope Corporation has been moving in the complete oposite direction as Lutris and AD. They've recently opened their CVS to community check-ins, and are working with RMS to make their already open-source license GPL compatable.

When Zope Corporation hired the PythonLabs team, they heartily agreed to turn over the copyright of Python to Guido van Rossum personally, to be later transfered to the a community led Python Software Foundation a non-profit organization whose members consist of all of the developers who have CVS check-in ability.

It's obvious (to me, at least) that you can't build a sucessful open-source application based on a closed source platform like Java. Sooner or later, the virus of commercialism will invade the mindset of all the layers above it. Immagine if Apache, or Emacs were written in a closed source language. They would not be what they are today.

So, hopefully all those folks will learn their lesson and switch to a real open source object-oriented web application platform like Zope.

Probably the only application server you can have up and running in 2 minutes. Plus since its all python based, you can get tracebacks and debug the thing live. Lots of cool new method-specific caching features all built in. DAs for lots of different DBs, transactions etc. Solid community, BBSs, CMS, image galleries etc. Check it out! Ya might like it.

Probably the only application server you can have up and running in 2 minutes. Plus since its all python based, you can get tracebacks and debug the thing live. Lots of cool new method-specific caching features all built in. DAs for lots of different DBs, transactions etc. Solid community. Check it out! Ya might like it.

Three relevant links to read in considering Zope for XML are:

Creating XML Applications With Zope

Create a XML Based Document Repository

Cant Handle Humongous XML

In some data management scenarios, using Zope obviates the need for XML markup. In practice, content management issues like security, revision control, and online access through a browser are bigger issues than markup. Zope provides solutions to all these problems.

My main caveat in using Zope is that finding all the relevant documentation for XML or anything else is a veritable Easter egg hunt. The Zope API doesn't seem to be documented in one place. More than once a Zope tutorial seriously proposed that the reader read the Python source code for further information.

Three relevant links to read in considering Zope for XML are:

Creating XML Applications With Zope

Create a XML Based Document Repository

Cant Handle Humongous XML

In some data management scenarios, using Zope obviates the need for XML markup. In practice, content management issues like security, revision control, and online access through a browser are bigger issues than markup. Zope provides solutions to all these problems.

My main caveat in using Zope is that finding all the relevant documentation for XML or anything else is a veritable Easter egg hunt. The Zope API doesn't seem to be documented in one place. More than once a Zope tutorial seriously proposed that the reader read the Python source code for further information.

Have you considered zope? It is perfect for storing a document tree, it has strong support for XML, including an extension for DocBook and supposedly it integrates with Apache. Gives you also lots of options to format the
XML as Html.

Let everybody argue about what's the best architechture, I'll just get on with it & adapt later.

OK, more than one word - so sue me!

True.

So what? Java and .NET are both 80%-hype and 20%-actual usefulness (in the case of .NET, 20% vapourware....as for Java, I love it, but it's really not the answer to everything)...I think that the Mono project is so incredibly stupid that I have deleted GNOME off my hard disk on principle and have installed KDE 2.1.1.

Component-based, clusterable, n-tier, etc etc. Wow. A lot of buzzwords there. Luckily, there is an Open Source solution that is clusterable, object-orientated and object-based, has support for SOAP, XML, XML-RPC and is fully scalable (yes, it runs on any architecture with a C compiler and a Python port). It also integrates very easily with other systems and can practically be used and extended to do anything thanks to the source code being open. You know what I'm talking about - Zope.

Wow, you're either trolling here (congrats, +5 indicates a pretty good troll. Check out Zope. Zope products and ZClasses make pretty reusable code...this technology has been out since 1999. You obviously don't "know of" all that much. As for Apache's lost market share, well, I won't waste my time worrying about it - neither will anyone else that uses it. A lot of the people I've talked to running IIS have been thinking seriously about changing over to Apache in these last few weeks.

Yer losing me, Janeway...

I love Java. I'd be very happy if everyone started using it, but I thought I'd just point out that a lot if it IS hyped, and for some things, I actually prefer to use other systems. The great thing is that with complex systems, you aren't tied to one development tool or system. With stuff like Python out there (or Perl), you could write your system in a variety of languages and use glue components to tie them together into one coherent system. That's what I often do, and in fact, on the Intranet running at work, the setup looks something like this: An Apache/FreeBSD front end, with a Zope/FreeBSD server running behind it through ProxyPassReverse, and a Debian GNU/Linux box running the latest JDK behind it and running Tomcat.

My guess is the author has never actually admin'd Apache. He's probably been just an Apache user his whole life. (I see nothing to the contrary in his bio at the bottom of the article). Apache is a wonderful tool that is upto /any/ job we throw at it. Jakarta is a great example of a web-services enabling extension to the Apache project.

How about Zope? How come it wasn't mentionned at all?

Read this: it may not change your life, but it might just change your mind. If it does, mod it up ;)

Zope has Enterprise-level scalability and is the closest OS competitor to the most advanced Java app servers, with much, much more and no Java BS.

However, Zope is more advanced than those, and has now:

• Enterprise clustering with ZEO; replication will improve with ZEO2
• Built in object database, strong XML tools, and modular access RDB access to Oracle, Sybase, ODBC, MSSQL, MySQL, PostGres, etc
• Built in object catalog and search engine, could be used as a front end for WSDL generation and code/method organization
• Best/Quickest development scripting language for Large-scale development out there - Python is THE secret weapon.
• SOAP (3rd Party), XML-RPC (Built-in)
• Built-in security model - No need to force app developers to invent one. Allows for basic http auth as one of MANY means for authenticating web services!
• Built-in transaction system
• Built-in content managment features, and web-management interface.
• Powerful content managment framework featuring pluggable tools/services
• Everything is OO - web services IS object publishing! Zope has been publishing objects for YEARS...
• Improving Unicode and internationalization support
• Supports Utility methods and automation to be written in Perl and Python
• Develop on the filesystem in Python modules, or through the web with ZClasses and method instances.
• Cluster safe session tracking WITHOUT THE NEED FOR A RDB TO DO IT!

Improvments being made continually via current Projects:

• Full exposing of Zope to web services via WSDL and services registries
• New component model where objects assert interfaces and services can be bolted on
• Use of Zope in desktop applications using XML-RPC and/or ZEO clients
• Improving scalability of object database infrastructure.
• Politically correct for all camps: Zope and Python's licenses are University-type, but are both moving toward a single license with GPL compatibility.

Zope is open-source, works well with Apache and Squid, has great RDB abilities. It naturally exposes objects for publishing using a strong, easy to use security model. It supports authentication off of LDAP, NT Domains, RADIUS, etc. It's odb catalog features allow the development of applications that use dynamic queries to organize content (and potentially code) objects. It's the strongest suite of features for web-services oriented middleware out there, because it has a several year lead in many respects on the competition! Python is XP, so it has the same advantages as a CLR, provided it is coupled with an XP GUI component model or class library, like PyXPCOM (Mozilla) or wxWindows (Unix, Win32, Mac). Last, but not least, it is easy to develop for.

An open challenge to all the folks trying to develop their own toolkits from scratch (dotGNU, Mono, etc): DON'T - instead use something that is already proven in this problem domain: Zope and Python!

www.zope.org

www.python.org

The problem with security is not that we don't know what to do. The problem is that so many of us don't do anything. That is what alarms Gibson, and in that he is correct. There are so many machines not being properly managed that damage is inevitable.

Given that at least four components are necessary for a crack to be effective, removing any one of them will prevent the problem. These components are: malicious code, vulnerable service or device, access to same, lack of fixes or unwillingness to apply available fixes.

Evolution suffers the same type of problems. Hypermutation was recently discovered in components of an immune system and many hands were waved about what this proved. What was not explored was the nature of the mutations. They are almost deliberately allowed to ``go wild'' within very strict bounds, and the result (which would be disastrous outside the immune system) is that a large set of possibly useful responses are produced and tried as antigens in a very short time. However, if any one of a large set of very specific conditions were not met, hypermutation would be lethal. And you can safely bet that any retractions of the previous headlines will be four lines of fine print on page twenty.

So, given that convenience will tend to be chosen over better security (and partly becuase if an administrator goes for a more secure but less convenient solution they may actually suffer a greater security problem by encouraging (for example) undocumented sharing of passwords), a solution such as replacing Windows plus IIS with Linux/*BSD/whatever plus Apache will actually work, and much better than telling users and administrators that they're idiots. They either know that and have to live with it, or don't know it, never will, and will be annoyed every time someone tries to point this out.

ASP2PHP exists, and works, so there's no really sound reasons left for running IIS. It's also (especially in the name of avoiding monoculture) worthwhile checking out alternatives like Zope. The combination of an inherently more reliable service, and automated updates (I know that Debian, Mandrake and RedHat - at least - have these) will remove a vital section from the crackers' stairway to heaven.

Where Mr Gibson does score is in that not everyone needs to be running vulnerable servers to swamp and drown the Internet. Just enough twits to do the job. I'm currently wondering what social effect would drive IIS market penetration up 4% at the very instant this it's been shown to be a public menace. Again. Remember that it's been copping buffer overflows for the best part of a decade now, and doesn't look like stopping.

I was unable to find any software to create, review, store & update scientific knowledge on any particular subject. In hot areas of molecular biology new papers are published daily. No one has time to search and read everything that is relevant to his field of interest. It takes plenty of time to find most important papers, to obtain copies of it (in print or pdf) and to dig throw all unimportant parts of the paper that has to be included because you can not link (hyperlink) directly to certain paragraph in another paper.

I think that we need to switch from paper type publications (where earch paper consist of redundant data and is linked to other papers by references only) to knowledge-base like publishing. The knowledge base on any field of science may be stored in object oriented database with schema that is like table of contents taken from any "scientific bible" (i.e. "Genes VII"). The table of contents might be followed by another layer containing very condensed information (like in scientific reviews) that has links to titles of scientific publications, or better to one sentence summary of scientific finding of any particular publication. The next layer may consist of data taken from publication abstracts (containing everything impoprtant) with links to crude data. Each piece of crude data should be logically presented with rationale (reason for that experiment), discussion of crude result and links to exact paragraphs of other publications. Each fact stored in the database should be linked to crude data. The crude data should be taken from publications or direct submissions and of course before inclusion into the database it must be peer reviewed. The crude data may also include the probability of it's reliability (set by author or reviewers). The reliability is important because some results are obtained with methods that give reliable results, but many of the research in molecular biology provide only indirect evidence.

This scientific-knowledge database will remove most of the redundancy found in all scientific publications published as articles.

To create such a system you can start with object oriented database (i.e. ZOPE or object-relational PostgreSQL or MySQL that has good full text search). Please not that the database will contain trilions of hyperlinks, and link management will be very important part of it. It should have system for peer review (maybe similar to slashdot moderation). It will store crude results that are in hundreds of different formats. Each single crude result with additional data and files may be stored in one tar.gz or zip file. There must be also a some kind of versioning system. You will have to provide external editor or list of compatybile editors that suport XML format. Maybe OpenOffice? And last but not least - there must be a system that enable researcher to claim that this work is theirs. To obtain further funding scientist need to be able to show what research was done. In science the position of each researcher is based on how many papers he/her published in best scientific journals. Scientific journals has impact factro - if papers published in the journal are cited often - the impact factor of the journal is high.

-Piotr

www.zope.org

You'd lose, because truth is an absolute defence. Regardless of whether or not you think the GPL is a good thing, it's obviously viral. That's precisely the right word to use. The GPL is like a grabby child that says "if you play with one of my toys, then I own your toy". No wonder businesses stay away from it.

I'm not slamming the GPL. I think it's a fair deal in many circumstances. As somebody else already said, it's really just a formalized code trade. But there's lots of times when you need to be able to retain control of your original code for business reasons. Or even purely selfish reasons. In those cases, code released under the GPL automatically disqualifies itself from use. Software released under freer licenses like Zope or Squishdot is much more useful because it allows you to retain control over derivative works.

Python is very powerful - it's killer app is Zope. Zope Makes PHP, Mod Perl and just about every commercial application server out there look *very* lame.

You should really have a look at zope.
It's object based, based on python (also OO) and also supports multiple inheritance, which is very handy for factoring you application into small components (classes), which "lend" their specific capabilites to your application's objects via mixin classes. This is very nice to seperate "orthogonal" capabilites into different locations (classes).
You get all the facilites of java you mentioned above with zope.
A good overview about the theoretical aspects of zope (and more) can be found at http://www.dieter.handshake.de/pyprojects/zope/boo k/chap3.html.

I've been using Webware lately, which is a Python servlet engine. Very similar to the Java servlets, except without a lot of the verboseness that Java demands. For Python there's Zope as well, but I found it unwieldy, and not very Pythonic.

Zope allows faster creation of dynamic sites and the ability to manage thousands of pages via user priveledges built into the Zope platform. ASP is ok for quick hacks (but not as good as Perl, PHP or Python), but for large sites, using raw web scripting can be time consuming. Zope allows scalability using the ZEO clustering, which basically takes a Zope Object from the Zope Object Database (built into the Zope Platform) and balances the requests over a cluster of Zope Servers using replication and synchronization...and maximum flexibility by being fully open source. Zope Methods can be written and the Zope platform can be extended using the amazing ZClasses API, one of the cleanest I've seen.

I seem to have it more and more these days: A sudden instant of strange clarity as I try to figure out what Zope is, or as I download a .wav file of Guido van Rossum squawking about "Vooty Vootpecker".

It's brief, but highly concentrated: The scales fall from my eyes, and I say to myself: "I don't give a rat's ass about this bullshit. Hooray for those that do, but I just don't." So, I close the browser window and find something interesting to spend my time on.

You know what? It just happened again.

However, I think that an ASP port for UNIX should be completely free, opensource and so on.

So write it. This 'I think' stuff get none of us anywhere.

ps: Huzzah for Zope! ;)

I've used Chili!Soft ASP on Linux and whilst it works, I'll be very happy not to ever use it again. Here's why.

The reason ASP is a winner in the win32 world is the availability of third-party COM components to do all the heavy lifting. The ASP "developer" generally just writes VBScript to hook this stuff together. More advanced developers might write their own components, but the reason it's so popular is that you don't have to.

This isn't the case under Linux, with Chili!Soft ASP... The third-party components aren't there (no binary compatability between platforms), so all your logic has to be done in your scripting language, eg VBScript - which soon ceases to be fun. You can write your own components but it's decidedly non-trivial, much more so than in the win32 world where the tools for doing so are well developed.

I'll stick to Python I think. And especially Zope.

-Andy
--

The Halloween 2 memo specifically lists Software Patents as a way to battle Open Source Software and Linux threats. I bet they won't be afraid to use this patent when they feel cornered by OSS or Linux.
Martijn Pieters, Software Engineer
Digital Creations, Creators of Zope

Python ( http://python.org/ )
+ Qt ( http://www.thekompany.com/projects/pykde/ )
+ Firebird ( http://firebird.sourceforge.net/ )
+ gvib ( http://www.zope.org/Members/RETierney/gvibDA )
=
A delicious cross-platform substitute for my obese friend Swing.

---

Is inside the organization. The money is in providing portals to an organization. A portal for an organization would have some combo of hotmail for mail, kuro5hin for news, and other apps running on zope. Those portals are a way of putting a front end on the organization's intranet.