sm-sorcery AT lists.ibiblio.org
Subject: Discussion of Sorcery related topics
List archive
- From: Sergey A Lipnevich <sergeyli AT pisem.net>
- To: Aaron Brice <abrice2 AT cox.net>
- Cc: Tony Smith <tony AT smee.org>, sm-sorcery AT lists.ibiblio.org
- Subject: Re: [SM-Sorcery]Language wars...
- Date: Tue, 08 Oct 2002 09:50:40 -0400
Aaron Brice wrote:
On Mon, 2002-10-07 at 08:59, Sergey A Lipnevich wrote:Follow Hans Reiser's notes on why file system will become a database later on. Facinating read. For now, FS is about ten times faster, versatile, flexible, easier to set up, and it works. Sorcery has all kinds of problems with structure, like needing to grep things because you simply can't take the value off the shelf using variables, selectors, or somehing like this which is easy.
One of the things neglected about Sorcery is that it relies on the file
system as its primary storage, a kind of database. Spell name's primary
source is its directory name, /not/ the name in DETAILS, so your first
example is wrong. If DETAILS has the spell name different from its
directory name, it's a bug. So, in your example 1, there is no need to
parse DETAILS files at all.
Using the file system as a kind of database in my opinion is one of
sorcery's weaknesses right now. Why not use a database as a kind of
database? How much faster would finding dependencies be if you could
just "select from dependency_table where depends_on='mozilla'"? I think
it would be great to not only switch to Perl, but to switch to Perl,
MySQL, and XML.
The anser to this is that, those files that are not executable, need to have structure kind of "built-in". XML may be the answer here. All the attempts to enforce structure by using colon-separated lists etc are just an attempt to do what XML does best -- present information in a structured way. So, I'd say sorcery 2.0 may enforce XML for non-executable files, and make one of XML libraries/tools a required component. For a large collection of small snippets of data, which the grimoire is, "file system + XML" combo has much more to offer than any relational database with rigid structure and SQL as the only access language.
As a side note, look how much easier it is to embed an API-only Berkeley DB than it is any SQL-oriented database. All kinds of software depend on the `db' spell because of it. Even MySQL ;-).
$DEBUG is one example of passing information beteen scripts. Assigning things like VAR=${VAR:-NEWVALUE} in /etc/sorcery/config is another way of allowing you to redefine the sorcery and spell environment. Whatever system you create, you have to manage persistence /and/ build for flexibility. In a central script model, you would create gazillion command line options to achieve this.Environment is one of the components of the application platform, so,
however unusual that may sound, bash is our application platform,
because it is our tool of maintaining state during execution. Note that,
using Perl, you have to change the structure of sorcery to at least have
a central script that runs everything, otherwise your execution state is
gone whenever the script finishes -- Perl's VM doesn't stay in memory
after the script has finished, bash does. If we choose Mono, this will
be our application platform, but it requires a server, for the same
purpose -- maintain execution state.
This is not an issue. In the current structure there is always a
central script that calls other scripts, right?
Please see above.That's why bash is better than anything as a lightweight application
platform -- it stays between script executions, Perl, Python, C++, etc,
do not have such advantage without extra effort. It has many programming
disadvantages, but believe it or not, it's not the worst infrastructure
we may have.
Can you give an example of a script that runs and relies on an
environment variable set by another script that's not its parent? Seems
like bad design to me..
Whatever does the job is the best tool in the world. Although Perl may be /the/ greatest /language/, it's not the greatest /tool/ for every task.How's that for language wars :-)?
There's no point in getting into a language war since it's obvious to
everyone that perl is by far the greatest language ever invented. I'm
going to include a "smiley" now in order to indicate the joking nature
of the previous statement. :)
Aaron
Sergey.
-
Re: [SM-Sorcery]Language wars...
, (continued)
- Re: [SM-Sorcery]Language wars..., Robin, 10/10/2002
- Re: [SM-Sorcery]Language wars..., ML, 10/10/2002
- Re: [SM-Sorcery]Language wars..., Robin, 10/10/2002
- Re: [SM-Sorcery]Language wars..., Ryan Abrams, 10/10/2002
- Re: [SM-Sorcery]Language wars..., Tony Smith, 10/08/2002
- Re: [SM-Sorcery]Language wars..., Dufflebunk, 10/08/2002
-
Re: [SM-Sorcery]Language wars...,
Aaron Brice, 10/08/2002
- Re: [SM-Sorcery]Language wars..., Dufflebunk, 10/08/2002
- Re: [SM-Sorcery]Language wars..., Aaron Brice, 10/08/2002
-
Re: [SM-Sorcery]Language wars...,
Sergey A Lipnevich, 10/08/2002
-
Re: [SM-Sorcery]Language wars...,
Tony Smith, 10/08/2002
-
Re: [SM-Sorcery]Language wars...,
Sergey A Lipnevich, 10/08/2002
-
Re: [SM-Sorcery]Language wars...,
Tony Smith, 10/08/2002
- Re: [SM-Sorcery]Language wars..., Sergey A Lipnevich, 10/08/2002
- Re: [SM-Sorcery]Language wars..., Dufflebunk, 10/08/2002
- Re: [SM-Sorcery]Language wars..., Sergey A Lipnevich, 10/08/2002
-
Re: [SM-Sorcery]Language wars...,
Tony Smith, 10/08/2002
-
Re: [SM-Sorcery]Language wars...,
Sergey A Lipnevich, 10/08/2002
-
Re: [SM-Sorcery]Language wars...,
Tony Smith, 10/08/2002
Archive powered by MHonArc 2.6.24.