I can't answer all of your questions. The mailing list would be the place to ask.
2. Next question, can Haskell be embedded inline in Perl code?
Not that I'm aware. However, all you need is an embeddable Haskell interpreter. I believe this is possible with Hugs, which has a "server interface", and possibly even with ghc (the native compiler that Darcs is compiled with). You'd probably have to write the C/Perl interface yourself.
3. Can the quantum theory of patches be implemented as a Perl module...
Certainly.
4. Reading about the symmetry or lack of it, concepts of physics this is helping me think about an app of my own. I'd like to read more about this does anyone have links?
More than anything it's mathematics. But David Roundy, the author of Darcs, is a physicist, and may have some pointers for you.
5. Time to learn Haskell!! Great!
If you're a Perl hacker, you might be interested in this. Scary, eh?
The distributed features are what make darcs unique.. it doesn't seem to me to be any fundamentally easier or faster for basic revision control than subversion, though.
Subversion seems similarly easy to get started with, but what about repository sharing? To let other people access your repository, you must set up a server of some kind, be it WebDAV, or svnserve -- although I'm sure Subversion must support something like an "ssh://" protocol.
I believe the term you're looking for is self-hosting. Subversion, for example, was originally maintained in CVS, and has a CVS gateway for maintaining redundant systems.
For pilot-testing a migration to Darcs, there are scripts available that convert other repository formats (Subversion, CVS, possibly others) into Darcs (and back, actually), so you avoid losing history when making the transition.
While "Darcs is written in a Haskell, a functional language that is relatively unknown compared to C or Perl", this really does hurt it's common use.
I call bullshit. First, the language that a product is written in doesn't hurt use -- it only affects the development process.
Secondly, what's in a language? I didn't know Haskell until I started looking at Darcs; now I know a bit of Haskell, and soon I hope to be proficient enough to contribute.
There's something to be said for language agnosticism. Haskell is a fine -- even brilliant -- language. The code is there, it's readable for anyone with half a brain.
In the end, the fact that Darcs is written in Haskell will not stop most people from being interested in developing it. Or at least, not the people you'd want to contribute; it's a nice prejudice filter.
A community project will ultimately be the versioning system for community projects.
That sentence does not make sense. Are you saying the same people who use a version control system should also develop it? I'm sure you will find that most CVS users have never seen even a line of the CVS source code.
Now your repository contains all your files. Let's look at the changelog:
john@somewhere$ darcs changes Thu Nov 25 06:26:19 CET 2004 johndoe@example.com * Initial import.
Now, where's the server? You need a server to share your repository, right? Nearly -- every repository is a potential server, as long as it's accessible either through the file system, through SSH/SFTP, HTTP or email. Let's go to another machine and check out the repository we just made:
jane@elsewhere$ darcs get john@somewhere:~/myproject Copying patches... . Finished getting.
We now have a repository on Jane's box. Let's make a modification:
This last output, by the way, is Darcs' patch format. A "hunk" is a line-based diff. Other types of changes that may be contained in a changeset include renames, moves and binary changes. (Yes, you can also get a GNU-patch-compatible output similar to "cvs diff".)
Now let's commit and push the changes back to John's repository:
jane@elsewhere$ darcs record -am "Added a missing include." jane@elsewhere$ darcs push -a [...] Finished applying...
Now we can go back to John's machine and look:
john@somewhere$ darcs changes Thu Nov 25 06:26:10 CET 2004 janedoe@example.com * Added missing include.
Thu Nov 25 06:26:19 CET 2004 johndoe@example.com * Initial import.
(Note how Darcs generates a GNU-style changelog for you automatically.)
Where are the revision numbers, you ask? Well, they don't exist, because they're not needed. Darcs is changeset-oriented, not file-oriented. You can refer to a changeset by name, date, or a special hash identity.
Darcs changesets aren't just GNU patches; they have context, which means, for example, that someone can check out a repository, move a file "foo.c" into the directory "bar" and commit; meanwhile, another person, working on an older copy of the same repository, edits foo.c (which is still in its old location) and commits that. Darcs know that this edit should apply to foo.c in the new location -- and unlike CVS, you don't need to do anything similar to "cvs update" if you're committing files that have been changed on the server. In other words, people can freely commit changes, and the only kind of visible "conflict" will occur when you actually edit the exact same line.
Unlike CVS and Subversion, but like Arch and Monotone, Darcs is a distributed version control system. Repositories are islands which are constantly out of sync with each other, and Darcs' patch commutation system takes care of integration the changes that flow between them.
This system has several extremely useful effects:
Offline mode. You can commit changes even if you're on the road with no access to the server. That's because your own working directory is a repository in its own righ
JSR166, the specification implemented in JDK 5.0, is essentially an improved, cleaned-up version of Doug Lea's public-domain util.concurrent package, a set of pattern-based building blocks for concurrent programming that have been very popular; Doug Lea himself is the specification lead on JSR166.
The util.concurrent package has been very popular among open-source projects, and is known for its strong performance. In many cases, migrating from util.concurrent should be as simple as importing java.util.concurrent.class instead of
EDU.oswego.cs.dl.util.concurrent.class.
Of course, one of the improvements made by JSR166 is to genericize all the interfaces and classes, so what uses to be a BlockingQueue is now a type-safe, parameterizable class BlockingQueue<E>.
Not all of the toolkit made it into the 5.0 release in time, and
the missing stuff, referred to as jsr166x, which comprises "concurrent sorted maps and sets, as well as concurrent double-ended queues (deques)", is available for use.
Zope and its CMS framework, Plone.
Take Plone for a spin. It's a breeze to install. The entire system is web-managed down to the core, with a flexible role-based security architecture.
Zope is written in Python, so you avoid the PHP stack and its evils. Unlike PHP, Zope is designed around object-oriented concepts such as encapsulation.
For example, to interface with a database you typically create (again, through the web) a connection object, then an SQL method describing the data (a pure SQL script with a few special HTML-like tags for specifying parameter slots) and finally a page template which calls the method.
The upshot? You just decoupled the data from the presentation in a very elegant way, and you decoupled the data operators from the data source. Abstraction is the key.
Plone, in turn, abstracts much of Zope away to provide an elegant, extensible GUI for managing user-oriented content. It has a workflow system, a component system, WYSIWYG article editor support etc.
(The workflow system allows complex flows such as "both John and Jane must review and accept the article before it can be published, and after they've reviewed it, spelling wizard Bob must look over it before it for typos; but users Jack and Jill are trusted users who don't require John or Jane's approval to post articles.)
Unlike most other CMSes, Plone/Zope have no external dependencies -- no MySQL needed, for example.
And how is the meaning behind a string of characters given? For example, lets say you want to give the meaning behind a strong of characters that describes to a human the proof of Skolem's Paradox.
It's given by marking it up. The computer doesn't need to know anything about the proof of anything, just like Google doesn't know anything about porn, and yet when you search for "big boobs", it knows what to return. *wink*
The point isn't that a computer program will ever "know" what Skolem's paradox is, in the same way a human would "know" what it is. The semantic web isn't about building artificial intelligence into computers, but rather adding knowledge statements to information.
Based on this information, I could ask the computer for pictures of all the other German scientists who were awarded the Nobel prize in 1921, or some other time. Clearly the computer doesn't need to know about nationalities, or dates, or to understand pictures.
There are simpler use cases, too. Say there's a product called Paradox (well, there used to be one). People searching for just the word "paradox" might get matches for pages about "Skolem's paradox". But if the pages were appropriately marked up, Google (or whatever) could ask you whether you meant a specific paradox, just the way Google currently asks if you perhaps meant something else.
Re:Zope great in theory ... not so much in practic
on
Zope X3 3.0.0 Released
·
· Score: 1
And what other options do you have available then ?!?
The most popular (and flexible) one is WebDAV, but Zope also supports FTP. Many editors (Eclipse, Emacs, vi) support seamless editing through these formats, either out of the box or with plugins.
Yes, I agree that PHP is ugly. But it's easy and it does the job.
I would argue that doing PHP cleanly -- cleanly enough for it to scale with your application -- takes a lot of effort. At some point you will grow to reach a threshold where the benefits of PHP will be canceled out by the effort to fight its warts. And I would argue that you reach that stage pretty quickly.
PHP is extremely dirty in places. For example, the default [at least in Debian's PHP distribution] fallback of variable lookup into the (if I remember correctly) $_SESSION dictionary is horrendous. There's a lot to be said for making all warnings terminal -- that it doesn't stop execution on references to uninitialized variables is just mind-boggling.
And how many times have you seen things like:
Warning: mysql_connect(): Too many connections in/vhosts/foo/etc/config.php on line 12
in the middle of some page? I'm sure it can be prevented, but it shows that the shoddier a programming language is, the harder it is to compensate for its shoddiness.
Don't get me wrong, I'm all into the benefits of the "worse is better"/MIT-versus-New-Jersey way of thinking, but look a Python -- a dynamically-typed, in some eyes "unsafe" language that manages to be incredible good. While PHP is a proof that simplicity increases productivity, Python shows that you can have the simplicity of PHP without sacrificing what PHP has sacrificed in terms of architecture and linguistic robustness.
I like clean languages, so I truly wanted to like Zope, but its deep non-intuitiveness killed my interest. Sorry.
Your loss. *wink*
Zope has a certain learning curve, to be sure, but getting over the initial hurdle -- and many Zope developers will tell you this -- results in a "zen" moment that will change the way you look at application development and never look back (at PHP) again. In other words, a little goes a long way.
As a developer fostered on the concept of object-oriented (*) programming, Zope is incredibly intuitive to me, and PHP isn't. The fact that PHP starts with the notion that a source module is a page is, to me, ass-backwards. Or ass in front, if you like.
(*) And I don't mean C++ class inheritance crap. I mean the idea of modularity, separation of concerns, encapsulation, composition -- it doesn't have anything to do with classes, and can be practiced in pretty much every Turing-complete language.
Re:Zope great in theory ... not so much in practic
on
Zope X3 3.0.0 Released
·
· Score: 1
Yeah, I couldn't believe it when I saw it. I thought it must have been just for the first step in Zope, then I searched where the files (template and other elements) were saved so I could access them directly with my editor of choice. No go, it's inside a database.
You didn't look far enough. The "textarea" editing is optional.
I gave up Zope and stuck to PHP soon after that (and the fact I could not wrap my mind around their 'TAL' thingy, call me dumb).
Each to his own. However, looking at the horrible code that PHP forces you to write, I would chalk this one up as shooting yourself in the foot. With a Magnum.
(And whoever invented the idea of putting code in templates deserves the same treatment.)
Okay, I tried Zope once a LONG time ago. Back when I was hungry for a good dynamic object-oriented language and Python was the best I could find. Naturally I sought an application framework as well.
Just keep in mind that you're comparing Rails today to Zope of yesterday. Apples to oranges, really.
Zope was pretty.. bloated, complex, confusing, opaque.
Zope is clearly complex, clearly confusing, but I would be hard pressed to call it bloated. Opaque? One of the (minor) design problems of Zope is that it's too transparent, with internal mechanisms leaking through all over the place.
And Python isn't suited to HTML templates at all (being whitespace-sensitive and all). So you need to learn Yet Another Way of generating HTML from code.
Nobody in the right mind would use Python for HTML templates. Zope has never used Python for HTML templates.
Incidentally, are you implying that one should mix code and presentation logic? What happens when you need the same code to produce an RDF view of the same data? Do you duplicate the code in a new component, or insert complex "if format == 'rdf'" switches into your template?
As for Zope, it provides TAL, an XML-based language which supports Python expressions (which, in case you're not too familiar with Python, are not whitespace-sensitive):
Zope is to J2EE as wiki is to the web
on
Zope X3 3.0.0 Released
·
· Score: 2, Informative
Is it really an Application Server and if so what services does it provide?
"Application server" is an overloaded buzzword. What do you mean by it?
Zope is a transactional object database with a security layer and an HTTP interface built on top.
The object databases give you a structure for containing content; the security layer controls access; and the HTTP interface lets you publish that content in whatever way you like.
The usual way to use Zope is to store content (eg., documents, images, external data sources), which is manipulated by logic (eg., Python scripts, SQL scripts) and rendered to (X)HTML (eg., with templates).
To illustrate the power that Zope gives you, the entire management interface is built with Zope. To create a site, you build it inside your browser.
If you think this is weird, think about wikis.
Of course, Zope is powerful enough to offer alternative access mechanisms. You can build your site in your own file system, then upload it using WebDAV, for example.
I ask because the programmers tutorial makes it look like a run of the mill framework for generating webpages.
It isn't. And there's nothing "run of the mill" about Zope.
Is it compiled into native code?
Parts of Zope, and parts of Python, are written in C. Most of the code is in Python. Python is compiled into interpreted bytecode, but if you install Psyco, a profiler-based JIT compiler similar to Sun's HotSpot, it will be compiled into native code on the fly.
I know this is more a Python thing but even mentioning an application server built in a scripting language will have me ridiculed out the door.
Python is not a scripting language, though. I think the day when people laughed at you for mentioning/using Python is long gone by.
Any performance indications or comparissons? Anyone port Petshop and compare it against JBoss or Geronimo perchance?
I don't have any comparisons to offer, but Zope is fast and scalable. Zope's performance is nevertheless its weakest aspect. However, compared to many application servers, it flies.
What advantages does Zope offer me over a J2EE server?
There are numerous advantages, but I'll just mention one: Time to market. I can prototype and deploy an application faster than it takes you to boot your IDE and create your EJB classes, and it will be modular, object-oriented, secure and instantly usable.
I can go on vacation without my PC, and get a call from a customer who has a problem with a page. All I need to work is a PC with a web browser -- an Internet café will do.
Good recommendation -- unfortunately (1) I can't afford to pay for buying and co-locating an additional box to act as firewall for my Linux box, and my Linux box is definitely not going to become OpenBSD in the near term; and (2) blocking malicious network traffic is only part of being secure.
This reminds of a question I've been pondering lately, which I believe would be on topic.
I have a box on a public IP -- speaking as a person who cannot devote 24/7 to security, are there any good automated tools to verify its "openness" in terms of security vulnerabilities?
I'm not talking about just potential root exploits and the like, but also about things like file permissions, which I find are hard to get exactly right on Unix (read: Linux with no special ACL stuff installed), where the file system does not support inheritance of security attributes.
Many Linux distros come with a script that's run nightly to report potential vulnerabilities, changed files etc. There are also tools like Snort and Tripwire. I also use Munin and check it daily for signs of DOS attacks and other suspicious activity (eg., a sudden increase in the number of listening ports).
What other automated tools do people here recommend?
Ther are only Linux x86 and Windows builds so far, and only RPM-packaged binaries are provided. You are also required to create an account on their project site to download (!).
And the license may be "open source", but it is not "free software".
CA seems to want it both ways -- they want to release the product as open source and to build a user base of hackers, but they also want to control the source and the process.
On the other hand, they have already set up mailing lists, a Subversion repository, a bug tracker and a wiki. Let's hope they can nurture their developer community with the same grace as, say, the Eclipse Foundation.
We're also talking about a huge product here, with pretty old code, a strangely obfuscated code tree layout, and a lack of documentation. It will take years before new developers know the sources to the extent that they can comfortably hack it. Just look at the huge amount of time it took for the PostgreSQL people to grok the whole codebase.
Incidentally, the version that has been released so far is incomplete. From the readme:
Due to some unresolved problems, the following features are not currently supported in the Ingres r3 Open Source, but will be supported in a future release:
* Linux Cluster support
* Cluster Failover (Windows Only)
* Bridge server
* Ingres Web Deployment Option (Windows Only)
* Parallel Query (Windows Only)
* Online Modify (Windows Only)
* Language Certification on Japanese, Korean, Simplified Chinese and Traditional Chinese.
Slightly off topic, is Apple the only ones producing cheap widescreen standalone LCDs these days? I'm thinking of upgrading my CRT, but after getting used the PowerBook's 15" widescreen, that's the kind of aspect ratio I would want. Minimum 1600 pixels horizontal resolution. Any recommendations?
Eclipse's plugin model is based on vendor-neutral, open standards. It's called OSGi.
That's just the plugin model, mind you, which is not specific to Eclipse; it just specifies the way plugins are packaged, declare their metadata, are loaded, accessed etc.
Eclipse's object model, which rests on top of this framework, is something else, and that's Eclipse-specific. Eclipse's object model is much more generic and vast in scope than NetBean's OpenIDE API.
In case you don't know the Eclipse plugin system well, it's a modular design based on loose coupling of components all extending each other.
There's no central plugin point to speak of; Eclipse is essentially a collection of loosely-coupled components, with some glue at the bottom to bootstrap the core plugins.
Every extension can potentially extend another. For example, if I provide a view, then I can let anyone extend that view by, say, providing context menu items, toolbar buttons, visual overlays and the like.
These extensions would all communicate using publicly declared APIs; hidden inter-component communication is discouraged.
For example, if I were building a stock trading app, I might write a bunch of different views -- graph view, a table view, a ticker view, etc.; the table view would expose a mechanism to detect when the user has clicked on a specific stock symbol.
The graph view would plug into this mechanism and change its view to show the currently selected stock. However, the graph view would not know anything about the view into which it was plugging into; it would only know about the interface contract of the extension point, which could be anything.
You could potentially bundle each of these views separately and mix and match with other, third-party views: as long as they know the public interfaces, they can talk to each other. I could write a better graph view and plug it in without having to change any code in any other view.
The reason Eclipse is so flexible, and is popularly touted as an "integrated anything environment", is precisely because it is so loosely defined.
Eclipse would not be able to use the NetBeans APIs directly because they are, well, NetBeans. Eclipse could not do everything it does today if it adhered to the NetBeans API.
Also, NetBeans/OpenIDE is tightly coupled to Swing, and while SWT can embed Swing, consistently and seamlessly adapting Swing-using components into the SWT environment would be a lost cause.
But I tried netbeans 4.0 beta the other day and I liked what I saw. Out of the box it supports a lot of stuff that eclipse simply does not support (basically all the j2ee stuff, ant integration, xml, html). You can get most of these things in eclipse by installing commercial plugins but if you want everything for free it's pretty hard to find e.g. jsp support, good servlet container integration (more than the pathetic tomcat start/stop support in some eclipse plugins), etc.
A nice thing about Eclipse is that it's modular, and distributed as such.
If you want everything in one box, you can download Yoxos, an Eclipse distro that comes with a ton of open-source plugins.
As for J2EE, if you're not into bleeding-edge software, until the Web Tools project is ready for production use you might want to check out Lomboz, an extremely popular plugin that provides JSP support, J2EE wizards, app server launching/debugging, web services support and much else.
While I'm sure you are right, it sounds like you're trying to fit a square peg into a round hole here. Derby is a relational database (or at least a specimen of its drooling imbred cousin variety, the SQL database) and therefore designed to store relations.
The relational model supports any kind of data structure ever invented, but it's true that you sometimes want to store opaque blobs of data such as graphics or XML documents, and most databases, including Derby, supports that as well.
Perhaps you should look at an object-relational mapping layer such as Hibernate or
TJDO, or a hybrid object database such as Prevayler.
Slashdot Mirror
This may be useful
Not that I'm aware. However, all you need is an embeddable Haskell interpreter. I believe this is possible with Hugs, which has a "server interface", and possibly even with ghc (the native compiler that Darcs is compiled with). You'd probably have to write the C/Perl interface yourself.
Certainly.
More than anything it's mathematics. But David Roundy, the author of Darcs, is a physicist, and may have some pointers for you.
If you're a Perl hacker, you might be interested in this. Scary, eh?
Subversion seems similarly easy to get started with, but what about repository sharing? To let other people access your repository, you must set up a server of some kind, be it WebDAV, or svnserve -- although I'm sure Subversion must support something like an "ssh://" protocol.
For pilot-testing a migration to Darcs, there are scripts available that convert other repository formats (Subversion, CVS, possibly others) into Darcs (and back, actually), so you avoid losing history when making the transition.
- While "Darcs is written in a Haskell, a functional language that is relatively unknown compared to C or Perl", this really does hurt it's common use.
I call bullshit. First, the language that a product is written in doesn't hurt use -- it only affects the development process.Secondly, what's in a language? I didn't know Haskell until I started looking at Darcs; now I know a bit of Haskell, and soon I hope to be proficient enough to contribute.
There's something to be said for language agnosticism. Haskell is a fine -- even brilliant -- language. The code is there, it's readable for anyone with half a brain.
In the end, the fact that Darcs is written in Haskell will not stop most people from being interested in developing it. Or at least, not the people you'd want to contribute; it's a nice prejudice filter.
That sentence does not make sense. Are you saying the same people who use a version control system should also develop it? I'm sure you will find that most CVS users have never seen even a line of the CVS source code.
Like CVS, you can get productive within minutes; the same cannot be said for Arch or even Subversion. Let's see:
You now have a Darcs repository! Let's do something with it:
Now your repository contains all your files. Let's look at the changelog:
Now, where's the server? You need a server to share your repository, right? Nearly -- every repository is a potential server, as long as it's accessible either through the file system, through SSH/SFTP, HTTP or email. Let's go to another machine and check out the repository we just made:
We now have a repository on Jane's box. Let's make a modification:
This last output, by the way, is Darcs' patch format. A "hunk" is a line-based diff. Other types of changes that may be contained in a changeset include renames, moves and binary changes. (Yes, you can also get a GNU-patch-compatible output similar to "cvs diff".)
Now let's commit and push the changes back to John's repository:
Now we can go back to John's machine and look:
(Note how Darcs generates a GNU-style changelog for you automatically.)
Where are the revision numbers, you ask? Well, they don't exist, because they're not needed. Darcs is changeset-oriented, not file-oriented. You can refer to a changeset by name, date, or a special hash identity.
Darcs changesets aren't just GNU patches; they have context, which means, for example, that someone can check out a repository, move a file "foo.c" into the directory "bar" and commit; meanwhile, another person, working on an older copy of the same repository, edits foo.c (which is still in its old location) and commits that. Darcs know that this edit should apply to foo.c in the new location -- and unlike CVS, you don't need to do anything similar to "cvs update" if you're committing files that have been changed on the server. In other words, people can freely commit changes, and the only kind of visible "conflict" will occur when you actually edit the exact same line.
Unlike CVS and Subversion, but like Arch and Monotone, Darcs is a distributed version control system. Repositories are islands which are constantly out of sync with each other, and Darcs' patch commutation system takes care of integration the changes that flow between them.
This system has several extremely useful effects:
What's this PostGRE thing you're talking about? It's called (and spelled) PostgreSQL.
The util.concurrent package has been very popular among open-source projects, and is known for its strong performance. In many cases, migrating from util.concurrent should be as simple as importing java.util.concurrent.class instead of EDU.oswego.cs.dl.util.concurrent.class .
Of course, one of the improvements made by JSR166 is to genericize all the interfaces and classes, so what uses to be a BlockingQueue is now a type-safe, parameterizable class BlockingQueue<E>.
Not all of the toolkit made it into the 5.0 release in time, and the missing stuff, referred to as jsr166x, which comprises "concurrent sorted maps and sets, as well as concurrent double-ended queues (deques)", is available for use.
Doug also offers a JSR166 maintenance update that fixed a bug in one of the classes.
Zope is written in Python, so you avoid the PHP stack and its evils. Unlike PHP, Zope is designed around object-oriented concepts such as encapsulation.
For example, to interface with a database you typically create (again, through the web) a connection object, then an SQL method describing the data (a pure SQL script with a few special HTML-like tags for specifying parameter slots) and finally a page template which calls the method.
The upshot? You just decoupled the data from the presentation in a very elegant way, and you decoupled the data operators from the data source. Abstraction is the key.
Plone, in turn, abstracts much of Zope away to provide an elegant, extensible GUI for managing user-oriented content. It has a workflow system, a component system, WYSIWYG article editor support etc.
(The workflow system allows complex flows such as "both John and Jane must review and accept the article before it can be published, and after they've reviewed it, spelling wizard Bob must look over it before it for typos; but users Jack and Jill are trusted users who don't require John or Jane's approval to post articles.)
Unlike most other CMSes, Plone/Zope have no external dependencies -- no MySQL needed, for example.
- And how is the meaning behind a string of characters given? For example, lets say you want to give the meaning behind a strong of characters that describes to a human the proof of Skolem's Paradox.
It's given by marking it up. The computer doesn't need to know anything about the proof of anything, just like Google doesn't know anything about porn, and yet when you search for "big boobs", it knows what to return. *wink*The point isn't that a computer program will ever "know" what Skolem's paradox is, in the same way a human would "know" what it is. The semantic web isn't about building artificial intelligence into computers, but rather adding knowledge statements to information.
If you tell a computer than Einstein is a scientist, that Einstein is a German, that Einstein won the Nobel prize in physics in 1921 and that this is an image of Einstein, then a computer will be able to infer that this picture is of a German scientist.
Based on this information, I could ask the computer for pictures of all the other German scientists who were awarded the Nobel prize in 1921, or some other time. Clearly the computer doesn't need to know about nationalities, or dates, or to understand pictures.
There are simpler use cases, too. Say there's a product called Paradox (well, there used to be one). People searching for just the word "paradox" might get matches for pages about "Skolem's paradox". But if the pages were appropriately marked up, Google (or whatever) could ask you whether you meant a specific paradox, just the way Google currently asks if you perhaps meant something else.
- And what other options do you have available then ?!?
The most popular (and flexible) one is WebDAV, but Zope also supports FTP. Many editors (Eclipse, Emacs, vi) support seamless editing through these formats, either out of the box or with plugins.I would argue that doing PHP cleanly -- cleanly enough for it to scale with your application -- takes a lot of effort. At some point you will grow to reach a threshold where the benefits of PHP will be canceled out by the effort to fight its warts. And I would argue that you reach that stage pretty quickly.
PHP is extremely dirty in places. For example, the default [at least in Debian's PHP distribution] fallback of variable lookup into the (if I remember correctly) $_SESSION dictionary is horrendous. There's a lot to be said for making all warnings terminal -- that it doesn't stop execution on references to uninitialized variables is just mind-boggling.
And how many times have you seen things like:
in the middle of some page? I'm sure it can be prevented, but it shows that the shoddier a programming language is, the harder it is to compensate for its shoddiness.Don't get me wrong, I'm all into the benefits of the "worse is better"/MIT-versus-New-Jersey way of thinking, but look a Python -- a dynamically-typed, in some eyes "unsafe" language that manages to be incredible good. While PHP is a proof that simplicity increases productivity, Python shows that you can have the simplicity of PHP without sacrificing what PHP has sacrificed in terms of architecture and linguistic robustness.
- I like clean languages, so I truly wanted to like Zope, but its deep non-intuitiveness killed my interest. Sorry.
Your loss. *wink*Zope has a certain learning curve, to be sure, but getting over the initial hurdle -- and many Zope developers will tell you this -- results in a "zen" moment that will change the way you look at application development and never look back (at PHP) again. In other words, a little goes a long way.
As a developer fostered on the concept of object-oriented (*) programming, Zope is incredibly intuitive to me, and PHP isn't. The fact that PHP starts with the notion that a source module is a page is, to me, ass-backwards. Or ass in front, if you like.
(*) And I don't mean C++ class inheritance crap. I mean the idea of modularity, separation of concerns, encapsulation, composition -- it doesn't have anything to do with classes, and can be practiced in pretty much every Turing-complete language.
- Yeah, I couldn't believe it when I saw it. I thought it must have been just for the first step in Zope, then I searched where the files (template and other elements) were saved so I could access them directly with my editor of choice. No go, it's inside a database.
You didn't look far enough. The "textarea" editing is optional.- I gave up Zope and stuck to PHP soon after that (and the fact I could not wrap my mind around their 'TAL' thingy, call me dumb).
Each to his own. However, looking at the horrible code that PHP forces you to write, I would chalk this one up as shooting yourself in the foot. With a Magnum.(And whoever invented the idea of putting code in templates deserves the same treatment.)
- Okay, I tried Zope once a LONG time ago. Back when I was hungry for a good dynamic object-oriented language and Python was the best I could find. Naturally I sought an application framework as well.
Just keep in mind that you're comparing Rails today to Zope of yesterday. Apples to oranges, really.- Zope was pretty
.. bloated, complex, confusing, opaque.
Zope is clearly complex, clearly confusing, but I would be hard pressed to call it bloated. Opaque? One of the (minor) design problems of Zope is that it's too transparent, with internal mechanisms leaking through all over the place.- And Python isn't suited to HTML templates at all (being whitespace-sensitive and all). So you need to learn Yet Another Way of generating HTML from code.
Nobody in the right mind would use Python for HTML templates. Zope has never used Python for HTML templates.Incidentally, are you implying that one should mix code and presentation logic? What happens when you need the same code to produce an RDF view of the same data? Do you duplicate the code in a new component, or insert complex "if format == 'rdf'" switches into your template?
As for Zope, it provides TAL, an XML-based language which supports Python expressions (which, in case you're not too familiar with Python, are not whitespace-sensitive):
Or without any Python at all:Rails looks like a nice framework, though.
- Is it really an Application Server and if so what services does it provide?
"Application server" is an overloaded buzzword. What do you mean by it?Zope is a transactional object database with a security layer and an HTTP interface built on top.
The object databases give you a structure for containing content; the security layer controls access; and the HTTP interface lets you publish that content in whatever way you like.
The usual way to use Zope is to store content (eg., documents, images, external data sources), which is manipulated by logic (eg., Python scripts, SQL scripts) and rendered to (X)HTML (eg., with templates).
To illustrate the power that Zope gives you, the entire management interface is built with Zope. To create a site, you build it inside your browser.
If you think this is weird, think about wikis.
Of course, Zope is powerful enough to offer alternative access mechanisms. You can build your site in your own file system, then upload it using WebDAV, for example.
- I ask because the programmers tutorial makes it look like a run of the mill framework for generating webpages.
It isn't. And there's nothing "run of the mill" about Zope.- Is it compiled into native code?
Parts of Zope, and parts of Python, are written in C. Most of the code is in Python. Python is compiled into interpreted bytecode, but if you install Psyco, a profiler-based JIT compiler similar to Sun's HotSpot, it will be compiled into native code on the fly.- I know this is more a Python thing but even mentioning an application server built in a scripting language will have me ridiculed out the door.
Python is not a scripting language, though. I think the day when people laughed at you for mentioning/using Python is long gone by.- Any performance indications or comparissons? Anyone port Petshop and compare it against JBoss or Geronimo perchance?
I don't have any comparisons to offer, but Zope is fast and scalable. Zope's performance is nevertheless its weakest aspect. However, compared to many application servers, it flies.- What advantages does Zope offer me over a J2EE server?
There are numerous advantages, but I'll just mention one: Time to market. I can prototype and deploy an application faster than it takes you to boot your IDE and create your EJB classes, and it will be modular, object-oriented, secure and instantly usable.I can go on vacation without my PC, and get a call from a customer who has a problem with a page. All I need to work is a PC with a web browser -- an Internet café will do.
Zope is to J2EE as wiki is to the web.
- I understand that the audience for
/. Has changed.
Dude, you're not using Word to write Slashdot posts, are you?You guys are right, the audience has changed.
*wink*
That was completely irrelevant. I would not use this even on Windows.
Good recommendation -- unfortunately (1) I can't afford to pay for buying and co-locating an additional box to act as firewall for my Linux box, and my Linux box is definitely not going to become OpenBSD in the near term; and (2) blocking malicious network traffic is only part of being secure.
I have a box on a public IP -- speaking as a person who cannot devote 24/7 to security, are there any good automated tools to verify its "openness" in terms of security vulnerabilities?
I'm not talking about just potential root exploits and the like, but also about things like file permissions, which I find are hard to get exactly right on Unix (read: Linux with no special ACL stuff installed), where the file system does not support inheritance of security attributes.
Many Linux distros come with a script that's run nightly to report potential vulnerabilities, changed files etc. There are also tools like Snort and Tripwire. I also use Munin and check it daily for signs of DOS attacks and other suspicious activity (eg., a sudden increase in the number of listening ports).
What other automated tools do people here recommend?
Comparison to other databases such as MySQL, Oracle and SQL Server
Ther are only Linux x86 and Windows builds so far, and only RPM-packaged binaries are provided. You are also required to create an account on their project site to download (!).
And the license may be "open source", but it is not "free software".
CA seems to want it both ways -- they want to release the product as open source and to build a user base of hackers, but they also want to control the source and the process.
On the other hand, they have already set up mailing lists, a Subversion repository, a bug tracker and a wiki. Let's hope they can nurture their developer community with the same grace as, say, the Eclipse Foundation.
We're also talking about a huge product here, with pretty old code, a strangely obfuscated code tree layout, and a lack of documentation. It will take years before new developers know the sources to the extent that they can comfortably hack it. Just look at the huge amount of time it took for the PostgreSQL people to grok the whole codebase.
Incidentally, the version that has been released so far is incomplete. From the readme:
Thanks, but any recommendations?
Slightly off topic, is Apple the only ones producing cheap widescreen standalone LCDs these days? I'm thinking of upgrading my CRT, but after getting used the PowerBook's 15" widescreen, that's the kind of aspect ratio I would want. Minimum 1600 pixels horizontal resolution. Any recommendations?
That's just the plugin model, mind you, which is not specific to Eclipse; it just specifies the way plugins are packaged, declare their metadata, are loaded, accessed etc.
Eclipse's object model, which rests on top of this framework, is something else, and that's Eclipse-specific. Eclipse's object model is much more generic and vast in scope than NetBean's OpenIDE API.
In case you don't know the Eclipse plugin system well, it's a modular design based on loose coupling of components all extending each other.
There's no central plugin point to speak of; Eclipse is essentially a collection of loosely-coupled components, with some glue at the bottom to bootstrap the core plugins.
Every extension can potentially extend another. For example, if I provide a view, then I can let anyone extend that view by, say, providing context menu items, toolbar buttons, visual overlays and the like.
These extensions would all communicate using publicly declared APIs; hidden inter-component communication is discouraged.
For example, if I were building a stock trading app, I might write a bunch of different views -- graph view, a table view, a ticker view, etc.; the table view would expose a mechanism to detect when the user has clicked on a specific stock symbol.
The graph view would plug into this mechanism and change its view to show the currently selected stock. However, the graph view would not know anything about the view into which it was plugging into; it would only know about the interface contract of the extension point, which could be anything.
You could potentially bundle each of these views separately and mix and match with other, third-party views: as long as they know the public interfaces, they can talk to each other. I could write a better graph view and plug it in without having to change any code in any other view.
The reason Eclipse is so flexible, and is popularly touted as an "integrated anything environment", is precisely because it is so loosely defined.
Eclipse would not be able to use the NetBeans APIs directly because they are, well, NetBeans. Eclipse could not do everything it does today if it adhered to the NetBeans API.
Also, NetBeans/OpenIDE is tightly coupled to Swing, and while SWT can embed Swing, consistently and seamlessly adapting Swing-using components into the SWT environment would be a lost cause.
- But I tried netbeans 4.0 beta the other day and I liked what I saw. Out of the box it supports a lot of stuff that eclipse simply does not support (basically all the j2ee stuff, ant integration, xml, html). You can get most of these things in eclipse by installing commercial plugins but if you want everything for free it's pretty hard to find e.g. jsp support, good servlet container integration (more than the pathetic tomcat start/stop support in some eclipse plugins), etc.
A nice thing about Eclipse is that it's modular, and distributed as such.If you want everything in one box, you can download Yoxos, an Eclipse distro that comes with a ton of open-source plugins.
As for J2EE, if you're not into bleeding-edge software, until the Web Tools project is ready for production use you might want to check out Lomboz, an extremely popular plugin that provides JSP support, J2EE wizards, app server launching/debugging, web services support and much else.
What's missing from Eclipse's Ant support?
The relational model supports any kind of data structure ever invented, but it's true that you sometimes want to store opaque blobs of data such as graphics or XML documents, and most databases, including Derby, supports that as well.
Perhaps you should look at an object-relational mapping layer such as Hibernate or TJDO, or a hybrid object database such as Prevayler.