Re: webmail

[Tim Sweetman]

Shevek wrote:
> 
> On Thu, 31 Oct 2002, Tim Sweetman wrote:
> 
> > I don't know whether PHP would behave any more gracefully.
> 
> Is dumping core considered graceful?

Compared with slurping memory forever or spitting to STDERR forever,
yes, very. One can't really fault a very ill person from leaving a
corpse. I feel that if they wander around zombielike attacking the
living, one has a legitimate grievance.

Cheers

Ti'

Re: webmail

[Tim Sweetman]

David Cantrell wrote:
> Let me clear up a few things here.  I wrote my toy system because I had an
> itch which needed scratching.  I looked at pre-existing alternatives and
> rejected them all for various reasons.  The only reason I'm even bothering
> to argue about this is because of the incorrect assertions coming from
> people who really should know better that my sort of solution inevitably
> leads to spaghetti code ... 

So everyone else thinks that templating systems are a good idea. So do
you, but yours is smaller. Much discussion ensues - probably boundless -
about exactly what the template system should, or shouldn't be able to
do... 

Your lightweight system is neither obvious, nor what any nonidiot would
do, nor necessarily trivial in any other nonCOBOL, nonAssembler
language, and therefore implicitly suggests Perl (or similar) and a
templating scheme rather like yours. And is not what everyone else was
saying would cause spaghetti code. 

You could mount similar arguments on virtually anything. Get rid of
$W==1 or strict, and you (and any other nonidiot) will do the right
thing anyway. Sure. Get rid of RDBMSs, and just store your data in
delimited, table-like files! It'll work. Doesn't *have* to lead to
spaghetti...

Cheers

Ti'

Re: compiling perl

[David Cantrell]

On Mon, Oct 28, 2002 at 07:00:02PM -0800, Randal L. Schwartz wrote:
> Here's how I build my Perl into /opt/perl/snap
> 
>   ./Configure -des -Dusedevel -Uversiononly -Dprefix=/opt/perl/snap 
>-Dlocincpth=/sw/include -Dloclibpth=/sw/lib [EMAIL PROTECTED]
> 
> It finds things in /sw just fine when you do that.

He all worky!

Randal++

-- 
David Cantrell

Re: webmail

[David Cantrell]

On Wed, Oct 30, 2002 at 10:52:06PM +, Lusercop wrote:
> On Wed, Oct 30, 2002 at 02:07:12PM +, David Cantrell wrote:
> > Remember, all software sucks*.  But to say that "embedding application code
> > in markup leads to a poor (or non-existant) seperation of concerned,
> > typified by spaghetti code" is to talk bollocks.
> > * - and absolutism in software sucks absolutely?
> Erm. I'm afraid I don't agree, please explain how embedding application code
> in page rendering information can *not* lead to a lack of separation between
> the two.

I would argue that seeing that the presentation is part of the application,
then the code in the presentation is part of the application code.  This is
regrettable, but unavoidable.  It should of course be kept to a minimum.
But you'll do that anyway so that you can have interchangeable interfaces
such as a web interface and a curses interface.  Seperate the heavy lifting
from the presentation by all means.  That's a Good Thing.

> I'm not quite sure what your definition of "spaghetti code" is. But I include
> in mine: chasing all over for the file containing the relevant module/method/
> function definition.

Oh well in that case, any use of modules is spaghetti.  There's at least
six different places that I might find perl modules on this 'ere machine,
with a completely stock installation of perl 5.6.1.

> As I've argued above, I think your starting point, that "it's possible to
> write non-spaghetti embedded templates" is actually flawed, due to what I
> consider to be spaghetti code.

Your definition would seem to be flawed, as above, and would in fact lead
to the conclusion that introducing what seperation we can between logic and
presentation is a bad thing.

> In your examples, such things as "where does
> this hash get initialised" are important, and are then "spaghetti" in terms
> of following them.

It was a trivial snippet, not a full application.  I can't be bothered to
post a full application, which would show the data coming from elsewhere.

> What Tim is saying, and FWIW, I think I agree with him on this, is "use the
> right tool for the job".

Excellent.  My problem is that the "business logic" gives me this 'ere
data structure, and it needs to be displayed prettily.  I know, I'll use
the Practical Extraction and Reporting Language.  Sounds like the ideal
tool for the job.

>  It's very easy to say "well, my way solves the
> problem of chopping up the carrots", and it does, however, it's not in the
> long term the best way of doing things. In the same way, using a templating
> system which properly separates code and data will help you in the long run,
> though it be more effort in the short, but you will get yourself into trouble
> if you don't.

Actually, I don't recall it being any effort in the short term either.
Creating the tiny templating system was no more work than a simple CGI
of the same sort of size.  FWIW, it's 49 lines of code, including comments,
and is not limited to HTML.

-- 
Grand Inquisitor Reverend David Cantrell | http://www.cantrell.org.uk/david

Considering the number of wheels Microsoft has found reason
to invent, one never ceases to be baffled by the minuscule
number whose shape even vaguely resembles a circle.
  -- anon, on Usenet

Re: webmail

[David Cantrell]

On Wed, Oct 30, 2002 at 10:08:42PM +, Tim Sweetman wrote:
> For spaghetti avoidance, "the right thing" tends to constitute
> nonspaghetti; separating stuff out; abstraction layers; passing the
> right data, and just the right data, to another part of the system
> through a comprehensible interface.

Yep, and all that's possible with my little toy system.  It doesn't force
it, true, but even so, if it results in spaghetti that's the user's fault,
as it is trivial to avoid.

> Firstly:
> "Trivial templates by variable substitution" is not an intuitive thing
> to do.

"The only intuitive interface is the nipple".  Although I imagine a good
stout club is up there with it.  Sadly, we're talking about computers.

>I'm doing it here, because DC did it earlier, because in a sense
> it removes content from presentation. However, a bunch of variables
> isn't something that you can (without heavy wizardry) simply pass
> somewhere else. You could pass each variable individually:
> 
> my ($width, $height, $iq, $motherfuckers_per_second, $foo, $bar,
> $blarch) = 
> $slimshady->vital_stats;

Eeuuuwww.  I'd refer to the slimshady->width accessor method when I
needed to spew the width to the output.  Remember, I'm abstracting
application logic out from the presentation.  slimshady would be an
instance of the Musician::Allegedly class, defined outside the template
and wrapped up in easy-to-reuse-and-not-tied-to-the-web-at-all goodness.

> Secondly:
> Except for trivial amounts of data, slinging data around in hashes, hash
> references, list references etc is good for this sort of application.

Welcome to the world of objects :-)

> "Trivial templates by variable substitution" does not make this
> particularly easy. Templating systems (well, TT and H::T) _do_.

In that case I guess that phtml isn't trivial in your view.  Personally,
I *do* think it's trivial, cos the implementation is only a few lines of
simple code and a couple of lines in the apache config.  I don't see why
people make such a song and dance about this stuff.

> Separating templates out also means it's easier to change appearance
> without changing functionality.

As I have, in fact, done on a site using my system.

>  It reduces friction between specialised
> graphic designers and coders. It keeps dreamweaver and emacs relatively
> happy.

Graphics designers, dreamweaver and emacs are of no interest to me, but they
wouldn't find my toy intolerable.

Let me clear up a few things here.  I wrote my toy system because I had an
itch which needed scratching.  I looked at pre-existing alternatives and
rejected them all for various reasons.  The only reason I'm even bothering
to argue about this is because of the incorrect assertions coming from
people who really should know better that my sort of solution inevitably
leads to spaghetti code and all the rest of the nastiness from Revelations.
If there's anyone here looking for a solution to their problem, I don't
want them to only hear the solution that I consider to be horribly over-
engineered.  And I certainly don't want them to reject potential solutions
based upon misinformation.

> It makes it easier to grep your source without running into
> fragments of HTML-or-whatever.

So isn't it a good thing that I don't have that problem!  I rock SO hard.

>All of which are good things in general,
> rather than spaghetti avoidance features in particular, and which go
> away if you start having Perl-like bits in your templates.

No, they do not.  They *can* go away *if* the user is an idiot.  But would
you let an idiot loose in your templates?  If your graphics designer is
messing around in the bits he's specifically been told not to mess with,
then HE is the problem.  If your HTML "coders" are too dense to understand
the few simple constructs they might need - like looping - then THEY are
the problem, and they can be easily replaced by out-of-work perl mongers.

> OK. You maintain that:
> > *any* templating
> > language is code embedded in presentation

Yup, if it's to let you do anything useful like dynamically build a visual
representation of a table of data.

> Loosely speaking, when we talk about code, we mean stuff that can do
> some of these:
> 1. implement an arbitrary algorithm
> 2. loop for an arbitrary period. Perhaps forever. Perhaps not.
> 3. perhaps do IO, perhaps system calls.
> 4. perhaps invoke your methods elsewhere within your system.

That list looks remarkably like it's been designed ex post facto to rule
me out.  I say that anything you write to tell the computer what to do is
code.  Turning data structures into nicely formatted tables counts.  Some
choose to invent a new language to do it in, whereas I was lazy and
impatient and used someone elses which, tbh, does a far better job than I
could in any reasonable time frame if I tried to create my own..

> A good language makes it easy to do what you're trying to do

Security wookie wanted...

[Dave Hodgkinson]

I have a london-based client who is looking for a security guru to
specify and implement a server configuration for handling an online
payment system. 

Mail me expressions of interest and pointers to previous similar
installations.

Ta,

Dave

Re: webmail

[the hatter]

On Thu, 31 Oct 2002, Alex McLintock wrote:

> I think I better learn PHP if for no better reason than to prepare for the
> mass PHP to perl/java conversions when people realise that PHP is a bad idea.

I learnt enough PHP to install and use a non-core module, and get that,
and database access, and cookies to interact.  I'm certainly no
uberprogrammer, and figured that our php programming lot could modify it
and make it 'more PHPish'  But no, my ropey first attempt is seemingly as
well structured as it gets.  I think it needs a big change, like that from
perl 4 to 5, to introduce namespaces and better scoping in general.  Also,
despite my experience, it was claimed that adding in more modules is a
pain - I can see that you'd have to recompile, link and then restart the
webserver, but that shouldn't be challenging.  But what perl modules give
is a middle way between compiled-in and include()d files.

Possibly what php is most missing is widespread usage for non-cgi stuff,
and with it, the programming experience of programmers taught to program,
rather than web or internet geeks, taught to do what's necessary to get
something working.


the hatter

Re: webmail

[Shevek]

On Thu, 31 Oct 2002, Tim Sweetman wrote:

> I don't know whether PHP would behave any more gracefully.

Is dumping core considered graceful?

S.

-- 
Shevek
I am the Borg.

sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print"$x\n";eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;&{$x}(\$x);};};}

foreach my $i (3..65535) { &{'2'}($i); }

Re: Proposal: Filesystem abstraction layer

[Dominic Mitchell]

Dominic Mitchell wrote:

sub set_something {
my ($self, $val) = @_;
*{$self}{something} = $val;
}


That should be:

${*$self}{something} = $val;

obviously...

-Dom

--
| Semantico: creators of major online resources  |
|   URL: http://www.semantico.com/   |
|   Tel: +44 (1273) 72   |
|   Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |

Re: webmail

[Dominic Mitchell]

Nicholas Clark wrote:

Except for one part that I find curious. The presentation lists one of
the cons for perl as

poor sandboxing, easy to screw up server

yet I get the feeling that that is the arguments against PHP. Or am I
confusing the idea of screwing up namespaces with screwing things up
between processes?


One problem I'm only too aware of is that mod_perl doesn't let you have 
different versions of modules installed into different vhosts.  We have 
a bunch of SEMANTICO::* modules and an apache with 4 vhosts. 
Consequently, we have to be extremely careful when changing those 
SEMANTICO::* modules so we don't change any interfaces.  It's doable, 
but it's not as convenient as per-vhost sandboxes.  If that's what PHP 
offers[1].

-Dom

[1] Never used php past a test page consisting of a single phpinfo() 
call.  :-)

--
| Semantico: creators of major online resources  |
|   URL: http://www.semantico.com/   |
|   Tel: +44 (1273) 72   |
|   Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |

Re: webmail

[Tim Sweetman]

Nicholas Clark wrote:
> Except for one part that I find curious. The presentation lists one of
> the cons for perl as
> 
> poor sandboxing, easy to screw up server
> 
> yet I get the feeling that that is the arguments against PHP. Or am I
> confusing the idea of screwing up namespaces with screwing things up

Well, from what I've seen, Apache/mod_perl stuff does not come with
things that protect against quasi-infinite loops, or infinite memory
bloat. You can put some of these in - BSD::Resource and
Apache::SizeLimit, for example - but you have to pick them, install
them, and test them. mod_perl, if it does run out of memory (ie, hits
its hard limit), has frequently responded (in the past) by jibbering
infinitely into the error log, until you run out of disk space, at which
point you find a puzzled sysadmin who has missed the "Out of memory!" in
the error log hidden by all the jibber. Even if it worked properly, this
would leave you with little idea that anything had gone wrong, or what
had gone wrong.

I don't know whether PHP would behave any more gracefully.

Cheers

--
Tim Sweetman |  http://www.thebunker.net/
A L Digital  |  "eXistenZ is _PAUSED_!!! *splat*" --- eXistenZ

Re: webmail

[Alex McLintock]

> http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm
> http://developers.slashdot.org/article.pl?sid=02/10/29/2052239

At 13:37 31/10/02, Nicholas Clark wrote:

Except for one part that I find curious. The presentation lists one of
the cons for perl as

poor sandboxing, easy to screw up server



I know of one large bank which does not support mod_perl because it 
believes some of its website users might mess up other users on the same 
boxes. They use perl cgi instead :-)

I think I better learn PHP if for no better reason than to prepare for the 
mass PHP to perl/java conversions when people realise that PHP is a bad idea.

And if they don't come around to thinking PHP is a bad idea, then well 
I will have just learnt PHP anyway

Alex





Openweb Analysts Ltd, London.
Software For Complex Websites http://www.OWAL.co.uk/
Open Source Software Companies please register here 
http://www.OWAL.co.uk/oss_support/

Re: webmail

[Nicholas Clark]

On Wed, Oct 30, 2002 at 04:38:12PM -0500, Chris Devers wrote:
> On Wed, 30 Oct 2002, << everyone >> wrote:
> 
> > << PHP is crap >>
> 
> http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm
> http://developers.slashdot.org/article.pl?sid=02/10/29/2052239
> 
> Erek Dyskant writes "Yahoo has decided to switch from
> a proprietary system written in C/C++ to PHP for their
> backend scripting. Here's the notes from a presentation
> by a Yahoo engineer at PHP Con 2002."
> 
> While I mostly agree with all the anti-PHP arguments, the Yahoo
> presentation makes a pretty good case as well. Any responses from
> those that are so vigorously ripping up the PHP straw man (which,
> after all, it is -- this isn't london.phpm, is it)?

Except for one part that I find curious. The presentation lists one of
the cons for perl as

poor sandboxing, easy to screw up server

yet I get the feeling that that is the arguments against PHP. Or am I
confusing the idea of screwing up namespaces with screwing things up
between processes?

Nicholas Clark

Re: php irony, was Re: webmail

[Andy Wardley]

Chris Devers wrote:
> When is it nice to be a "quick hack language" that's
> "simple and easy", & when does that lead to "the biggest no-no there is"?

Simple and easy quick hack languages are great.  I've got nothing against
PHP or Perl in that respect.  

But for larger projects that you want to be scalable, adaptable, easy to 
customise and maintain, the first rule, or one of the first rules is to
separate application code from presentation code.

In Perl, Ruby, Python or Java, you can choose to be lax and hacky or 
strict and structured.  You can apply the best technique as the situation
demands it.

In PHP you don't get that choice.  It's like you're always stuck in 
lax and hacky mode.  For that reason, I wouldn't recommend it for 
larger projects any more than I would receomment Perl 4.

That's not to say that people haven't written large and high quality systems
in Perl 4 or PHP, but I would suggest that they're the exceptions rather
than the norms.

A

Re: Proposal: Filesystem abstraction layer

[Dominic Mitchell]

Shevek wrote:

1) Is there any code I should look at already? I'm assuming that I will 
inherit IO::File and IO::Dir into my own File and Dir objects.

One of the best places to start is to look at the kernel and the 
vfs/vnode system within it.  I know it's C, but the basic ideas are 
pretty simple to pull out.  And it's how the real filesystem is 
implemented, so you should be able to match things up closely.

For example, nosing my FreeBSD kernel sources (Linux will have something 
similiar), I find under /sys/ufs/ffs the files ffs_vfsops.c, and 
ffs_vnops.c.  The important bits from the first one are details of how 
to mount it and super blocks and stuff like that, most of which is 
irrelevant.   The "mount" and "umount" methods are the main ones of 
interest, they would translates into setup points for your instance.

The vnops are what actually drive individual files.  Calls like read(), 
write(), realloc() and sync() go on here.

You may wish to look at:

Linux Device Drivers, 2nd Edition.
http://www.xml.com/ldd/chapter/book/index.html

Maybe it's a bit more than you need, but you might get some ideas out of 
all this.  :-)

On another note, I wouldn't inherit IO::File and IO::Dir.  I would 
rather have instances of them as attributes of your object.  The reason 
is that (IO::File in particular, not sure about IO::Dir) is based as a 
blessed typeglob, which might not be relevant to some subclasses.  If 
you're basing your VFS on an SQL RDBMS for instance, it would be of no 
use and it would make writing accessors more complicated than is necessary:

sub set_something {
my ($self, $val) = @_;
*{$self}{something} = $val;
}

It also blocks the use of useful tools like Class::Accessor.

-Dom

--
| Semantico: creators of major online resources  |
|   URL: http://www.semantico.com/   |
|   Tel: +44 (1273) 72   |
|   Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |

Re: GI Joe is a perl user

[Dominic Mitchell]

Lusercop wrote:

On Thu, Oct 31, 2002 at 10:57:40AM +, Alex McLintock wrote:


I spotted this article referred to from Ecademy...
Techweb: Defense Contractor Says Open-Source Software Is Good For 
Military > October 29, 2002
http://www.techweb.com/wire/story/TWB20021029S0005
The article says that the American Department of Defense quite likes Open 
Source software - *and* particularly mentions their heavy use of perl.


Yes, all the work that I did on OpenSSL, a lot of the work on TrustedBSD,
and some of the NSA's work on the trusted linux platforms plus some other
things were being sposored by DARPA and other branches of the US Military
Machine.


Just like the original BSD work on TCP/IP stacks[1] all those years ago. 
 It's not a new thing.  I'm surprised that it's taken the military that 
long to realise that it's been using open source since before it was 
called that.  Mind you, large organisation, one hand not knowing what 
the other's doing...

-Dom

[1] Even though Bill Joy threw out the code he was given and wrote his 
own.  ;-)

--
| Semantico: creators of major online resources  |
|   URL: http://www.semantico.com/   |
|   Tel: +44 (1273) 72   |
|   Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |

Re: Proposal: Filesystem abstraction layer

[Andy Wardley]

Shevek wrote:
> 1) Is there any code I should look at already? I'm assuming that I will 
> inherit IO::File and IO::Dir into my own File and Dir objects.

There are 2 TT plugin modules which provide a fairly basic form of 
this abstraction, Template::Plugin::File and Template::Plugin::Directory.

A

php irony, was Re: webmail

[Chris Devers]

On Wed, 30 Oct 2002, Andy Wardley wrote [and I slightly edited, sorry]:

> $LANG is, or should be, a quick hack language.  The fundamental
> feature of embedding application code directly in presentation markup
> is the biggest no-no there is.  It leads to a poor (or non-existant)
> separation of concerns, typified by spaghetti code programs that are
> all but impossible to read, understand, extend and maintain.
>
> $LANG is quick, simple and easy to use and ideal for basic one or two
> page web hacks.  But for building larger sites or dynamic web
> applications? Definately not!
>
> Alas, that's what most large dynamic web applications seem to be
> written in these days.  Written by your average Joe who wouldn't know
> the difference between good programming and bad, and probably wouldn't
> care much about it if they did :-(


Of course, the irony here is that, when talking to (say) Java people, this
whole argument can get thrown back at Perl as well. Set $LANG to Perl and
this could be a typical "Perl is line noise" boilerplate rant.


Which would make this hypothetical post script --


> PHP is just as bad for much the same reasons.  Used by people who
> don't know any better and don't want to know any better.


-- all the more ironic.


As Greg said, certain things (PM groups, YAPC, etc) have brought a level
of professionalism to Perl that maybe wasn't there before, but still --
these kind of accusations are still made all the time, and as long as
there is prominent bad Perl code out there (I'm trying to avoid saying
Matt Wright's name but whoops it just spilled out) accusations like this
will continue to be made, and not without foundation.

Thrown stones, glass houses, etc.

I find it ironic to hear Perl hackers saying these sorts of things about
PHP. If "quick, simple and easy to use" is such a crime, why are you using
Perl? I mean, I realize I'm not being entirely fair here -- I know that
many or most of the members of this list are much more disciplined than
that -- but still, the essential qualities that you're objecting to are
ones that for a long time have defined Perl & Perl Culture. So what's the
dividing line? When is it nice to be a "quick hack language" that's
"simple and easy", & when does that lead to "the biggest no-no there is"?



-- 
Chris Devers[EMAIL PROTECTED]

  Usenet is a co-operative venture, backed by nasty people.
  Follow the standards.
-- Chris Rovers, in the Monastery

RE: Proposal: Filesystem abstraction layer

[Ivor Williams]

On Thursday, October 31, 2002 11:15 AM, Shevek [SMTP:[EMAIL PROTECTED]] wrote:

> Questions:
>
> I intend to write this module.
>
> 1) Is there any code I should look at already? I'm assuming that I will
> inherit IO::File and IO::Dir into my own File and Dir objects.

Take a look at the File::Spec and other modules in the File:: namespace. Also 
read perldoc perlport, as this presents the current guidelines for writing 
portable code.

>
> 2) What should I call it and where should it live in the namespace?
>

How about File::System or File::Abstract

Re: GI Joe is a perl user

[Dave Cross]

On Thu, Oct 31, 2002 at 10:57:40AM +, Alex McLintock ([EMAIL PROTECTED]) wrote:
> I spotted this article referred to from Ecademy...
> 
> Techweb: Defense Contractor Says Open-Source Software Is Good For 
> Military > October 29, 2002
> http://www.techweb.com/wire/story/TWB20021029S0005
> 
> The article says that the American Department of Defense quite likes Open 
> Source software - *and* particularly mentions their heavy use of perl.

Plenty of discussion of this on the advocacy list over the last couple
of days.



Dave...

-- 
  Brian: Oh screw Maximilian!
  Sally: I do.
  Brian: So do I.

Re: GI Joe is a perl user

[Lusercop]

On Thu, Oct 31, 2002 at 10:57:40AM +, Alex McLintock wrote:
> I spotted this article referred to from Ecademy...
> Techweb: Defense Contractor Says Open-Source Software Is Good For 
> Military > October 29, 2002
> http://www.techweb.com/wire/story/TWB20021029S0005
> The article says that the American Department of Defense quite likes Open 
> Source software - *and* particularly mentions their heavy use of perl.

Yes, all the work that I did on OpenSSL, a lot of the work on TrustedBSD,
and some of the NSA's work on the trusted linux platforms plus some other
things were being sposored by DARPA and other branches of the US Military
Machine.

The way I see it is that the more time I can bill, the less they have
available to spend on a war with Iraq.

-- 
Lusercop.net - LARTing Lusers everywhere since 2002

Proposal: Filesystem abstraction layer

[Shevek]

As I write code that would like to mess with virtual filesystems, the 
following thoughts come to mind:

Introduction:

A filesystem is an object with methods like open file, stat file. A file 
is an object with methods like read, write, close. Many programs use 
filesystems. Many programs like to refer to a subset of the filesystem, 
and are given a 'root' directory as an argument to a constructor (e.g. 
Apache DocumentRoot).

A filesystem root is specified in the Unix kernel as a major and minor 
number pair for the device, and an inode number for the root inode. All 
operations performed by Unix system calls are relative to this data, and 
so the filesystem may be viewed as an object even at kernel level. To 
chroot a process, the kernel replaces these three numbers in the task 
structure (or wherever it lives).

Proposal:

An object 'Filesystem' having methods open, stat, ... giving an object 
oriented interface to a filesystem. A set of subclasses Filesystem::DBI, 
Filesystem::Disk, ... to give unified interfaces to the various ways of 
storing data.

Instead of passing a root directory as an argument, one would pass a 
Filesystem object.

Corollaries:

A Filesystem object would return File objects. A File object may be used 
to gain access to the Filesystem object on which it lives. A Filesystem 
may be a chroot'd subpart of another Filesystem. In this case, a File 
object created from it would return the sub-Filesystem not the parent.

Since any Filesystem can only access files within itself, an application 
given a Filesystem object for a sub-filesystem can never gain access 
through the Filesystem methods to any file outside the given space.

In other words, an application properly constructed using method based 
filesystems does not need to verify that paths do not contain '/../' 
substrings since the Filesystem will always resolve the path to something 
within itself.

In this sense, the object is a capability and works in the same ways as 
traditional capability systems.

Questions:

I intend to write this module.

1) Is there any code I should look at already? I'm assuming that I will 
inherit IO::File and IO::Dir into my own File and Dir objects.

2) What should I call it and where should it live in the namespace?

3) Any other business?

S.

-- 
Shevek
I am the Borg.

sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print"$x\n";eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;&{$x}(\$x);};};}

foreach my $i (3..65535) { &{'2'}($i); }

Re: Webmail

[Dominic Mitchell]

Dean Wilson wrote:

I'm going to ignore the PHP bashing and templating discussions and add that
Horde and SquirrelMail are both recommened on the GLLUG list when ever this
question comes up by a number of people. So while neither is written in
Perl both are in use.


I'm using an IMAP server here and never managed to get horde working 
properly.  Squirrelmail, OTOH, worked pretty much straight out of the 
box.  It does have a few quirks which I haven't ironed out yet though.

-Dom

--
| Semantico: creators of major online resources  |
|   URL: http://www.semantico.com/   |
|   Tel: +44 (1273) 72   |
|   Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |

GI Joe is a perl user

[Alex McLintock]

I spotted this article referred to from Ecademy...

Techweb: Defense Contractor Says Open-Source Software Is Good For 
Military > October 29, 2002
http://www.techweb.com/wire/story/TWB20021029S0005

The article says that the American Department of Defense quite likes Open 
Source software - *and* particularly mentions their heavy use of perl.

Alex



Openweb Analysts Ltd, London.
Software For Complex Websites http://www.OWAL.co.uk/
Open Source Software Companies please register here 
http://www.OWAL.co.uk/oss_support/

Re: Webmail

[Michael Styer]

On 30 Oct 2002, Dave Hodgkinson wrote:

> does anyone have any recommendations for webmail that won't degenerate
> into a templating argument?

http://fastmail.fm

OK, you can't install it anywhere, but it's far and away the best webmail
service out there. Supporting evidence includes:

* It plays nicely with IMAP and IMAPS
* It's written in Perl (hence this post is not OT ;) and it's
maintainers have contribued at least one module to CPAN
* It lets you use your own domains, and there are lots of others besides
fastmail.fm to choose from (like the particularly cool eml.cc)
* It has lots of the Funky Filtering Features that you'd probably want to
set up if you were hosting your own mailserver (like if a folder named
'folder' exists in your IMAP directory, mail to [EMAIL PROTECTED] 
gets automatically filed into it, as does mail to 
[EMAIL PROTECTED])
* You can write whatever horribly complex filtering rules you want in
Sieve, the Cyrus mail filtering language
* It has SpamAssassin and virus scanning already set up and running
* You can get whatever bandwidth and storage limits you want
* If you're looking to do corporate webmail, you can get them to change
the interface or set up a new CSS for your corporate L&F
* The interface is very good, clean, and uses almost no graphics so
downloads fast for people on a slow connection
* and probably more features that I haven't mentioned

There's even a free option if you want, but the paid-for options are not
expensive. No, I don't work for them. I just think they're good. (But on
the shameless plug note, if you do sign up, the correct answer when they
ask you for a referrer is 'mas' ;).

Michael

Re: webmail

[Dave Cross]

On Thu, Oct 31, 2002 at 09:27:14AM +, Greg McCarroll ([EMAIL PROTECTED]) 
wrote:
> * Chris Andrews ([EMAIL PROTECTED]) wrote:
> > 
> > The learning curve to writing *bad* PHP is really flat. The learning curve
> > to writing good, secure, scalable PHP I would suggest is much steeper and
> > longer, because the language itself, and also the user community (and so
> > the support and resources available) is so geared to writing quick-hack
> > code. 
> 
> Which was the state of Perl *plucks figure out of the air* 4 years
> ago. However during this time we've seen great advances in the way
> people develop in Perl. Off the top of my head I'd suggest the major
> forces in this advancement are (and this is imho),

[snip]

>   * YAPC
> YAPC conferences have meant there are a low cost alternative
> to TPC, meaning that people can still meet with their peers
> and learn from talks/tutorials even if they can't afford TPC.

At a lower level, I'd say the the Perl Mongers movement has also 
contributed a great deal in getting Perl programmers talking to each
other. For example, how many of your had met 5 other Perl programmers
before joining london.pm? I know I hadn't.

Dave...

-- 
  Brian: Oh screw Maximilian!
  Sally: I do.
  Brian: So do I.

Re: webmail

[Greg McCarroll]

* Chris Andrews ([EMAIL PROTECTED]) wrote:
> 
> The learning curve to writing *bad* PHP is really flat. The learning curve
> to writing good, secure, scalable PHP I would suggest is much steeper and
> longer, because the language itself, and also the user community (and so
> the support and resources available) is so geared to writing quick-hack
> code. 
>

Which was the state of Perl *plucks figure out of the air* 4 years
ago. However during this time we've seen great advances in the way
people develop in Perl. Off the top of my head I'd suggest the major
forces in this advancement are (and this is imho),

* Testing
  Testing has become easier and more fun in Perl, thanks to
  all the modules, articles, talks on the subject. (At this
  point I'd like to suggest to anyone who hasn't looked at
  Test::MockObject to look at it today)

* Template Toolkit
  Like TT or not, the emergence of a dominant templating
  system has stopped people in a lot of cases rolling their
  own, or hacking their own extensions onto H::T.

* YAPC
  YAPC conferences have meant there are a low cost alternative
  to TPC, meaning that people can still meet with their peers
  and learn from talks/tutorials even if they can't afford TPC.

* Perl 6
  Perl 6 is acting as a stimulus for the way people think about
  Perl and the Perl community (and its relationship to Python, 
  Java, et al.) Also I'm hoping we will see some aspects of
  Perl 6 make their way into 5.10 but there are already lots
  of modules on CPAN emulating Perl 6 RFC suggestions. Of all
  the driving forces this is perhaps the one which we haven't
  seen the most impact from so far, but I believe we will see
  more and more impact from it, in the next 6~12 months.
  
I've probably forgotten some of the improvements in the world of Perl
during this time, but the point remains Perl has matured in ``software
engineering'' terms, whatever that means and PHP still has to do so.

Anyway, thats just me tuppence ha'penny worth,

Greg

-- 
Greg McCarroll http://www.mccarroll.org.uk/~gem/
   jabber:[EMAIL PROTECTED]

Re: Webmail

[Simon Dick]

On Wed, 2002-10-30 at 22:42, Chris Devers wrote:
> On 30 Oct 2002, Dave Hodgkinson wrote:
> 
> > does anyone have any recommendations for webmail that won't degenerate
> > into a templating argument?
> 
> Yeah, I'm impressed that in all this thread (over 100 messages?) I think
> maybe one or two posts actually addressed the question. I was also looking
> forward to an answer to this one. If Squirrelmail is bad because it's PHP
> and $hand_rolled_with{$template} is even worse, then what doesn't suck?
> 
> I'd also like to set up such a thing, if any projects out there came
> recommended highly enough. Apparently nothing is better than all of them?

You'll be happy to know that SquirrelMail developers are looking into
templating it properly, but are concentrating more on cleaning up the
code first :)

-- 
Simon

Re: Webmail

[Lusercop]

On Thu, Oct 31, 2002 at 12:49:12AM -, Dean Wilson wrote:
> I'm going to ignore the PHP bashing and templating discussions and add that
> Horde and SquirrelMail are both recommened on the GLLUG list when ever this
> question comes up by a number of people. So while neither is written in
> Perl both are in use.

Squirrelmail tends to be the general answer on the exim-users list. Though
it is off-topic there. Caveat emptor: I've never used webmail, I'm not sure
that it's a service I want to offer.

-- 
Lusercop.net - LARTing Lusers everywhere since 2002

Re: webmail

[Simon Wistow]

On Wed, Oct 30, 2002 at 07:49:03PM -0800, Randal L. Schwartz said:
> I don't.  I suspect PHP runs more hobby sites.  I suspect Perl does
> more of the e-commerce heavy lifting and pretty-lifting.

Christ. I said I wasn't going to get pulled into this.

FWIW, according to the latest SecuritySpace survey
(http://www.securityspace.com/s_survey/data/man.200209/apachemods.html)
the number of mod_perl and mod_php installations is comparable (I've
taken to ignore the percentage changes because, a couple of months ago,
Perl was growing by 25% a month whilst PHP was decreasing by 12%)/

This of course doesn't count the number of places running Perl scripts
as plain CGIs.

As for the Yahoo! thing - I can only tell you so much but, as mentioned
in the report, we have *lots* of Perl code and our publishing system is
written almost entirely in Perl.

Currently we use 3 different templating languages - all proprietary -
some dating back almost from the days Yahoo! started. I have had a long
discussion with the other engineers and pointed out TT (which I thought
would have been a better match since we're slinging Perl objects from
the publishing system) and they we suitably impressed and may steal some
ideas.

>From what I can tell the reason for switching to PHP is (a) politics and
(b) all our current code is mixed code and presentation because, as I
mentioned, some of it dates back from days of yore. Converting to PHP is
a lot easier than converting to, say, TT.

I think, anyway. People are a bit cagey about the whole thing.


-- 
   an atmosphere of PhD student 
  with a touch of alternative elitist radical

Re: webmail

[Chris Andrews]

On Thu, 31 Oct 2002, Paul Makepeace wrote:

> On Wed, Oct 30, 2002 at 04:38:12PM -0500, Chris Devers wrote:
> > On Wed, 30 Oct 2002, << everyone >> wrote:
> > > << PHP is crap >>
> 
> I don't think PHP is crap.
> 
> I am also amused and puzzled at the people writing huge tracts on why
> PHP is crap while not at the same time acknowledging there are vastly
> more websites written in PHP doing useful things for lots of people than
> there are in perl -- witness the scrabbling to find even remotely
> interesting success story cases for Perl (what recent ones have there
> been?). I suspect more revenue is generated from PHP sites than Perl
> sites. As a corollary, there are less (by some metric) experienced
> people writing more web software in PHP than in Perl. PHP gets you sooo
> much more with the same amount of effort than with perl. PHP is
> fundamentally quite easy, the learning curve astonishingly flat. Hardly
> the case for perl.

The learning curve to writing *bad* PHP is really flat. The learning curve
to writing good, secure, scalable PHP I would suggest is much steeper and
longer, because the language itself, and also the user community (and so
the support and resources available) is so geared to writing quick-hack
code. Just look at the user comments on the PHP manual.

I'm sure there are people writing good PHP out there - the Horde and IMP
stuff I was quite impressed with - but they are lost in the noise of
people arguing the PHP equivalents of 'use strict is gay' over and over.

> "Worse" is "better".

Indeed. Perhaps there's a lesson there - but I'll stick to my Lisp
Machine, thanks.

Chris.