You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by kyle dawkins <ky...@centralparksoftware.com> on 2000/12/05 22:30:29 UTC
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Everybody
This whole call for mod_perl advocacy is definitely a good thing. But we're
not going to get anywhere unless we understand the problem in detail. We can
run around all we like talking numbers and touting the virtues of mod_perl
but it's not going to actually do anything unless we address some fundamental
issues. I don't claim to know the answers to these problems, but I do think
I can at least start the ball rolling the right direction to get others
thinking about what next.
If we're on this list, there's a good chance we think we have a good
understanding of mod_perl. Or at least a good understanding of the parts of
the massive mod_perl beastie that we use. I use it all day every day but
don't claim to know anything about Authentication, for example. I'm sure I
could read the chapters in the eagle book and figure it out, but I don't know
anything about it now.
So, making that assumption, I want to bring up a few issues that I see as
crucial.
1. We are worried that mod_perl is not being adopted as a server technology
in enough places. This is actually TWO problems, not one, and to treat is
as one is missing the point. There are TWO different kinds of developer out
there. The first is someone who is probably not a programmer by trade, but
has picked up CGI and/or PHP/ASP programming from a "21 days" book or by
reading through examples. There are a number of reasons why *these* people
have not jumped all over mod_perl... I'm sure we all know what those reasons
are. The second group of people are *engineers* (or *developers*). These
people need something different out of mod_perl. They need good docs,
examples, stability, community support, and FOUNDATION CLASSES (more on this
later)
2. Perl
Let's face it, we love Perl, but a lot of people don't, because *they don't
understand it*. Remember, a lot of people might have looked at Perl 4 when
it was a disastrous hodgepodge and not looked at it since. Perl 5 is an
infinitely better language than 4, but most people don't know that. In order
for Perl to be acceptable in larger institutions with an already-established
software engineering group, changes to Perl itself need to be made. See more
below.
3. Installation/setup
Ok, so if you have Linux, it's a piece of cake... download all the sources,
follow the README's, and go. But what if you don't have Linux? Or you
aren't root, and what if you need access to httpd.conf to keep changing
stuff? And developers are going to need to cycle the server all the time, so
they need the ability to do that, too... it's definitely a weak point. I can
install any one of the Java-based web application frameworks and be
developing immediately.
4. Isolation
A lot of mod_perl projects (or even Perl projects in general) tend to be
one-person shows... maybe I'm wrong, and I'd love it if people could correct
me! But in my observation, we have a lot of programmers working in
isolation. This is bad.
5. Foundation libraries
Because of the open nature of the CPAN community, there are a lot of great
modules floating around out there. However, there is no real API consistency
in them, and this will cause newcomers to Perl a fair amount of trouble.
Moreover, we're not going to get anywhere in the enterprise if people insist
on using HTML templating systems that allow the embedding of code within
HTML. It's straight up and down a total disaster and no right-minded
software architect would ever consider it.
which brings me to...
6. Engineering
The Perl community is made up of a truly eclectic group of people, which is
an amazing strength. However, it's also an amazing weakness: I get the
impression that very few programmers in the Perl community spend a lot of
time *reading* books on software engineering and techniques thereof... and
that lack of knowledge tends to bleed over into a lot of code out there. We
have a HUGE problem in the community of the "coder superstar" mentality...
which is very dangerous. Perl allows far too many tricks, and often code
ends up totally unmaintainable and unreadable because some coding yahoo put
in some glory-code. It happens in many languages, true, but Perl is the
ideal environment for it.
--> SO <--
I hope you guys can give these points some thought. I could be "smoking
grass" but I think I'm on target on most of my points and I'd love to hear
what you guys think too. In the meantime, here are some ideas that might go
down well (or not!):
* We implement a "mode" under mod_perl, kind of like "use strict", that
suddenly forces Perl to behave well from an object-oriented standpoint. By
this, I mean taking some of the power away from Perl that causes trouble,
like allowing anyone to write instance data on an arbitrary instance of a
class...
* We "homogenise" some foundation classes. This means we create a *suite* of
classes that have consistent API, are designed together as a framework, and
are easy to learn
* We need to drop-kick DBI out of the park... it's not that it's bad (it's
actually great... kudos to the DBI crew) but kind of the opposite; it's so
easy to use that most people don't think beyond it. How many of you have
ever thought about implementing an Object-Relational middleware layer using
mod_perl? We could create a set of generic OR classes as part of our
foundation framework.
Well? Anybody?
Cheerz
Kyle
--
kyle@centralparksoftware.com
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Posted by Buddy Lee Haystack <ha...@email.rentzone.org>.
I've always considered mod_perl similar to an artist's canvas, while Java is more like a craftsman's tool kit.
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Posted by Piers Cawley <pd...@bofh.org.uk>.
Robin Berjon <ro...@knowscape.com> writes:
> At 14:07 06/12/2000 -0500, kyle dawkins wrote:
> >Ok, you're missing my point but that's partially my fault for not explaining.
> > First, let me agree: Java's "everything is an object" mentality sucks
> >balls. And yes, Perl's duality of functional/OO is really nice. Taking that
> >away is not what I am advocating... I think there should be the *option* in
> >Perl to disable certain features that make Perl a dangerous language for OO
> >development. First and foremost, the lack of true encapsulation is
> >disastrous. There is no concept of private data because instance data is
> >stored in a blessed hash (typically) that's open wide to the world. It makes
> >it tough to create a true interface/implementation dichotomy that is
> >important in the OO world.
I've got the beginnings of an interface/implementation thing going
with Perl 5, check out ex::implements and ex::interface. They're still
not 100% there because I haven't actually written any real
documentation, and there can be problems with pre existing AUTOLOADs
for the non 'utterly strict' version, but there's the beginnings of
something decent. At least you now get an error thrown at compile time
if you haven't actually implemented everything you promised to
implement.
But until 'my Dog $spot' becomes an assertion that $spot can only be
either undefined, or something that implements the 'Dog' interface, my
code is just an experiment. Albeit a possibly useful one.
> That's because of the way most people implement their classes. Perl does
> have a concept of private date (although it's not built into the language
> as that) and it's actually fairly easy to get that. OO Programming with
> Perl by Damian Conway has plenty of example demonstrating that.
All hail Class::Contract. Slow as a dog 'cos of all the tie magic, but
*utterly* fantastic otherwise. Again, fingers crossed for Perl 6
making 'tie' or its moral equivalent nice and fast.
And there's so much in Perl that makes OO so *nice*. For instance, I
have a container class (It's a row in a shopping basket) that can be
fully specced completely independently of the stuff it contains and
yet, because of AUTOLOAD and 'can' it can present itself as if it were
the contained object to stuff that is expecting that. Which reminds
me, I really need to overload the container's 'isa' method so that it
can return true to C<$container->isa('Contained')>.
But then another problem arises: Because C<{}->isa(...)> throws an
exception, too much code ends up doing C<UNIVERSAL::isa($foo, 'Bar')>.
Good, friendly polymorphic behaviour would have
C<$unblessed_ref->isa(...)> and C<$unblessed_ref->can(...)> returning
sensible values. Some sort of $random_ref->is_blessed() method might
be handy too.
And here we are, too late for a perl6.language rfc...
--
Piers
Re: RFC: mod_perl advocacy project resurrection (and a
proposal!)
Posted by Robin Berjon <ro...@knowscape.com>.
At 14:07 06/12/2000 -0500, kyle dawkins wrote:
>Ok, you're missing my point but that's partially my fault for not explaining.
> First, let me agree: Java's "everything is an object" mentality sucks
>balls. And yes, Perl's duality of functional/OO is really nice. Taking that
>away is not what I am advocating... I think there should be the *option* in
>Perl to disable certain features that make Perl a dangerous language for OO
>development. First and foremost, the lack of true encapsulation is
>disastrous. There is no concept of private data because instance data is
>stored in a blessed hash (typically) that's open wide to the world. It makes
>it tough to create a true interface/implementation dichotomy that is
>important in the OO world.
That's because of the way most people implement their classes. Perl does
have a concept of private date (although it's not built into the language
as that) and it's actually fairly easy to get that. OO Programming with
Perl by Damian Conway has plenty of example demonstrating that. I also have
an inheritable Class::ArrayBased somewhere on my disk that provides a
framework for array based objects. Admittedly it's encapsulation through
obscurity (so to say) but people that understand how it works will probably
respect the encapsulation, while those that don't will fail to access the
content as a hashref.
-- robin b.
Make it idiot proof and someone will make a better idiot.
Re: RFC: mod_perl advocacy project resurrection (and a
proposal!)
Posted by Gunther Birznieks <gu...@extropia.com>.
I would agree. If you want to see design patterns in practical action with
relation to mod_perl.. go to
http://www.extropia.com/ExtropiaObjects/
and skim through Chapters 10 (App Architecture) and on (on the individual
app toolkit components). Each one contains a sidebar on how design patterns
affected the design of our application toolkit for CGI and mod_perl.
Later,
Gunther
At 08:33 AM 12/7/00 -0800, brian moseley wrote:
>On 7 Dec 2000, David Hodgkinson wrote:
>
> > Development are two of the bibles. I have to say though,
> > I've avoided the Design Patterns type books purely
> > because of the C++/Java bias.
>
>you sure are missing out.
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: modperl-unsubscribe@apache.org
>For additional commands, e-mail: modperl-help@apache.org
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Posted by kyle dawkins <ky...@centralparksoftware.com>.
On Thu, 07 Dec 2000 11:33, you wrote:
> On 7 Dec 2000, David Hodgkinson wrote:
> > Development are two of the bibles. I have to say though,
> > I've avoided the Design Patterns type books purely
> > because of the C++/Java bias.
>
> you sure are missing out.
I second that. You should lose your anti-engineering bias just because of
your anti-Java/C++ bias. Design patterns have nothing whatsoever to do with
Java and C++, and if you ignore them, you ignore solutions to problems that
plague every developer. Design patterns are fundamental to everything we do,
even if we don't know it. That's not to say that they will somehow solve all
your problems, but a responsible developer should learn about as many
problem-solving techniques as possible.
Ok, I'll get off my soapbox now.
:-)
Kyle
--
kyle@centralparksoftware.com
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Posted by brian moseley <bc...@maz.org>.
On 7 Dec 2000, David Hodgkinson wrote:
> Development are two of the bibles. I have to say though,
> I've avoided the Design Patterns type books purely
> because of the C++/Java bias.
you sure are missing out.
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Posted by David Hodgkinson <da...@hodgkinson.org>.
kyle dawkins <ky...@centralparksoftware.com> writes:
> On Wed, 06 Dec 2000 05:52, Matthew Byng-Maddick wrote:
> > > 6. Engineering
> > > The Perl community is made up of a truly eclectic group of people, which
> > > is an amazing strength. However, it's also an amazing weakness: I get
> > > the impression that very few programmers in the Perl community spend a
> > > lot of time *reading* books on software engineering and techniques
> > > thereof... and
> >
> > I'm not convinced about this. Although from my limited experience, I'm not
> > very fond of them....
>
> Hmmm, I'm not sure if you're talking about the programmers or the books. Ha.
> But seriously, I lose a lot of respect for people who don't continually
> study software engineering yet call themselves developers. Our craft is
> constantly evolving, and to ignore the material that's available to us to
> learn new techniques is completely irresponsible and it leads to some of the
> problems that we are bemoaning in this very thread.
I admit I read these kinds of books fairly often, although because of
the sites I do they can tend towards more general topics (Funky
Business, Cluetrain Manifesto), but Extreme Programming and Rapid
Development are two of the bibles. I have to say though, I've avoided
the Design Patterns type books purely because of the C++/Java bias.
That said, anyone who hasn't digested Damian Conway's OO Perl book is a
total slacker.
*snip*
Dave
--
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star http://www.deep-purple.com
Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
-----------------------------------------------------------------
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Posted by kyle dawkins <ky...@centralparksoftware.com>.
On Wed, 06 Dec 2000 05:52, Matthew Byng-Maddick wrote:
> > 6. Engineering
> > The Perl community is made up of a truly eclectic group of people, which
> > is an amazing strength. However, it's also an amazing weakness: I get
> > the impression that very few programmers in the Perl community spend a
> > lot of time *reading* books on software engineering and techniques
> > thereof... and
>
> I'm not convinced about this. Although from my limited experience, I'm not
> very fond of them....
Hmmm, I'm not sure if you're talking about the programmers or the books. Ha.
But seriously, I lose a lot of respect for people who don't continually
study software engineering yet call themselves developers. Our craft is
constantly evolving, and to ignore the material that's available to us to
learn new techniques is completely irresponsible and it leads to some of the
problems that we are bemoaning in this very thread.
> > that lack of knowledge tends to bleed over into a lot of code out there.
> > We have a HUGE problem in the community of the "coder superstar"
> > mentality...
>
> yup.
>
> > which is very dangerous. Perl allows far too many tricks, and often code
> > ends up totally unmaintainable and unreadable because some coding yahoo
> > put in some glory-code. It happens in many languages, true, but Perl is
> > the ideal environment for it.
>
> Not necessarily. You can get coder superstars who write maintainable and
> understandable code.
OK, terminology problem... I wouldn't call them "coder superstars" *if* they
write maintainable and understandable code. Perhaps I should have called
them "glory coders" instead. You're totally right, there are plenty of great
coders out there who conform to coding standards and don't write tricky code.
But what I mean is that there is an abundance of glory-coders in the Perl
community because, in a way, the community encourages it. That doesn't fly
in a large-scale project and greatly reduces the chances of mod_perl being
adopted in the enterprise (IMHO).
> > * We implement a "mode" under mod_perl, kind of like "use strict", that
> > suddenly forces Perl to behave well from an object-oriented standpoint.
> > By this, I mean taking some of the power away from Perl that causes
> > trouble, like allowing anyone to write instance data on an arbitrary
> > instance of a class...
>
> No. no no no. Forcing perl to behave as "Object oriented" is entirely the
> wrong thing. This is why Java sucks so much. "Everything is an object"
> (excepting, obviously, the language primitives). Perl is nice because you
> can write it functionally or object oriented depending on the problem
> you're trying to solve. Also this functionality is more core Perl than
> mod_perl.
Ok, you're missing my point but that's partially my fault for not explaining.
First, let me agree: Java's "everything is an object" mentality sucks
balls. And yes, Perl's duality of functional/OO is really nice. Taking that
away is not what I am advocating... I think there should be the *option* in
Perl to disable certain features that make Perl a dangerous language for OO
development. First and foremost, the lack of true encapsulation is
disastrous. There is no concept of private data because instance data is
stored in a blessed hash (typically) that's open wide to the world. It makes
it tough to create a true interface/implementation dichotomy that is
important in the OO world.
> > * We "homogenise" some foundation classes. This means we create a
> > *suite* of classes that have consistent API, are designed together as a
> > framework, and are easy to learn
>
> I think you need to get out of the "object-oriented-only" mentality. But
> yes, sort of, agreed.
Ummmm, remember, this thread is about mod_perl advocacy. In my mind, we will
have huge problems encouraging enterprise adoption of mod_perl without some
fundamental changes. No enterprise in its right mind would choose a platform
that is not OO for any large project these days. Regardless of whether you
like this or not (and I can tell that you don't), it's the truth... you said
it yourself. In order to fight the Java juggernaut, we have to beat them at
their own game. Perl has so many advantages over Java that that shouldn't be
a problem, yet it is. Primarily, it's one of perception... Perl is a
scripter's language, Perl is for hackers, Perl is great for sysadmin tasks...
but it's also a technical one. Java has a set of foundation classes that
everyone uses. They suck festering balls, but they're there. We can learn
from that and build a set of consistent classes that allow developers to
build web *apps*, not a shitload of scripts that kinda work together as
glorified CGI, which is what we get all too often now.
Yes, Java is a sorely broken language, but it's being adopted, partially
because of Sun's hype but also because it offers enterprise developers real
ways to encapsulate their business logic properly. There are a few reasons
why mod_perl can't fill the same role, and I think we should endeavour to fix
those things.
Cheers
kyle
--
kyle@centralparksoftware.com
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Posted by Tim Sweetman <ti...@aldigital.co.uk>.
Matthew Byng-Maddick wrote:
>
> On Tue, 5 Dec 2000, kyle dawkins wrote:
> > * We implement a "mode" under mod_perl, kind of like "use strict", that
> > suddenly forces Perl to behave well from an object-oriented standpoint. By
> > this, I mean taking some of the power away from Perl that causes trouble,
> > like allowing anyone to write instance data on an arbitrary instance of a
> > class...
People are looking at this sort of thing. Damian Conway wrote
Tie::SecureHash and Class::Contract, which may be driving at this sort
of thing.
The latter implements "design by contract", as seen in Eiffel. I read
Damien's paper on it, but haven't used it - there are four things that
put me off:
1. The difficulty of modifying existing classes to work with it
2. The magic of "flyweight scalars", which I haven't yet got my head
around
3. "This code is funky"-type disclaimers scare me.
4. It looks like he just defines "data types" as LIST, ARRAY, the usual
Perl primitives.
This is of limited use, IMHO; being able to _define_ rules for data
types (eg. valid URI;
reference to FooID in table Foo in database bar) would be more
powerful.
(Not that these should all be checked every time, unless you're
implementing a Snail,
but C::C does have the ability to switch checks off, eg, in a live
environment. Though live users
make very thorough testers :-/)
I can see why people want encapsulation, though I've rarely seen
problems due to people violating it. This may be pure luck. *Lack* of
encapsulation may provide clues when you hit something with Data::Dumper
& find out what's going on on the inside.
IMHO, assertions, data type definitions, pre & post conditions are v.
useful things. Define interfaces to methods & functions. This isn't
necessarily the right approach - especially at the beginning of a
project - but it is in some cases, and AFAIK there is little to automate
this stuff available in Perl. Putting up these walls can *really* help
isolate problems.
Eiffel & Class::Contract allow conditions to be *inherited*. So these
approaches work hand-in-hand with OO *and/or* re-use.
Cheers
--
Tim Sweetman
A L Digital
'Now you see this one-eyed midget shouting the word "now"...'
--- Bob Dylan
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Posted by Matthew Byng-Maddick <mb...@colondot.net>.
On Tue, 5 Dec 2000, kyle dawkins wrote:
[1. two types of developer]
agreed.
[2. Perl4 / Perl5 ]
This is also true. Although a lot of "Perl programmers" haven't got a clue
about the object orientation stuff in Perl5 either. On the other side of
the coin, too many people are jumping on the "It's object oriented, it
must be reusable" and "The only way to solve problems is using objects"
bandwagons. Java and C++ both play to these. And unfortunately they've
convinced management, in general. Plus, big corporates like to deal with
corporates - Java is defined by Sun, a corporate. This is always going to
make our life hard...
> 3. Installation/setup
> Ok, so if you have Linux, it's a piece of cake... download all the sources,
OK. but s/Linux/a UNIX or UNIX-alike/g.
> follow the README's, and go. But what if you don't have Linux? Or you
> aren't root, and what if you need access to httpd.conf to keep changing
Then you don't necessarily do it on port 80. This is the only reason you
need to be root.
> stuff? And developers are going to need to cycle the server all the time, so
> they need the ability to do that, too... it's definitely a weak point. I can
> install any one of the Java-based web application frameworks and be
> developing immediately.
I disagree. The webserver stuff still needs to be run as root, or you run
it on a different port. Although I would also suggest having a look at
userv (http://www.chiark.greenend.org.uk/~ian/userv/), although there are
some security holes opened up by using mod_perl.
> 4. Isolation
> A lot of mod_perl projects (or even Perl projects in general) tend to be
> one-person shows... maybe I'm wrong, and I'd love it if people could correct
> me! But in my observation, we have a lot of programmers working in
> isolation. This is bad.
<plug>http://codix.net/</plug>.
> 5. Foundation libraries
> Because of the open nature of the CPAN community, there are a lot of great
> modules floating around out there. However, there is no real API consistency
> in them, and this will cause newcomers to Perl a fair amount of trouble.
> Moreover, we're not going to get anywhere in the enterprise if people insist
> on using HTML templating systems that allow the embedding of code within
> HTML. It's straight up and down a total disaster and no right-minded
> software architect would ever consider it.
Agreed.
> 6. Engineering
> The Perl community is made up of a truly eclectic group of people, which is
> an amazing strength. However, it's also an amazing weakness: I get the
> impression that very few programmers in the Perl community spend a lot of
> time *reading* books on software engineering and techniques thereof... and
I'm not convinced about this. Although from my limited experience, I'm not
very fond of them....
> that lack of knowledge tends to bleed over into a lot of code out there. We
> have a HUGE problem in the community of the "coder superstar" mentality...
yup.
> which is very dangerous. Perl allows far too many tricks, and often code
> ends up totally unmaintainable and unreadable because some coding yahoo put
> in some glory-code. It happens in many languages, true, but Perl is the
> ideal environment for it.
Not necessarily. You can get coder superstars who write maintainable and
understandable code.
> --> SO <--
> I hope you guys can give these points some thought. I could be "smoking
> grass" but I think I'm on target on most of my points and I'd love to hear
> what you guys think too. In the meantime, here are some ideas that might go
> down well (or not!):
Not entirely.
> * We implement a "mode" under mod_perl, kind of like "use strict", that
> suddenly forces Perl to behave well from an object-oriented standpoint. By
> this, I mean taking some of the power away from Perl that causes trouble,
> like allowing anyone to write instance data on an arbitrary instance of a
> class...
No. no no no. Forcing perl to behave as "Object oriented" is entirely the
wrong thing. This is why Java sucks so much. "Everything is an object"
(excepting, obviously, the language primitives). Perl is nice because you
can write it functionally or object oriented depending on the problem
you're trying to solve. Also this functionality is more core Perl than
mod_perl.
> * We "homogenise" some foundation classes. This means we create a *suite* of
> classes that have consistent API, are designed together as a framework, and
> are easy to learn
I think you need to get out of the "object-oriented-only" mentality. But
yes, sort of, agreed.
> * We need to drop-kick DBI out of the park... it's not that it's bad (it's
> actually great... kudos to the DBI crew) but kind of the opposite; it's so
> easy to use that most people don't think beyond it. How many of you have
> ever thought about implementing an Object-Relational middleware layer using
> mod_perl? We could create a set of generic OR classes as part of our
> foundation framework.
DBI is actually quite a hassle to use sensibly, and I've got my own
library functions that call the DBI ones, and return errors in a way that
is consistent. I also have the run object open DB connections. (YATS)
<another plug>http://codix.net/ASPerl/</plug>.
MBM
--
Matthew Byng-Maddick Home: <mb...@colondot.net> +44 20 8981 8633 (Home)
http://colondot.net/ Work: <ma...@codix.net> +44 7956 613942 (Mobile)
Genius may have its limitations, but stupidity is not thus handicapped.
-- Elbert Hubbard
Re: RFC: mod_perl advocacy project resurrection (and a proposal!)
Posted by Dave Rolsky <au...@urth.org>.
On Tue, 5 Dec 2000, kyle dawkins wrote:
> * We need to drop-kick DBI out of the park... it's not that it's bad (it's
> actually great... kudos to the DBI crew) but kind of the opposite; it's so
> easy to use that most people don't think beyond it. How many of you have
> ever thought about implementing an Object-Relational middleware layer using
> mod_perl? We could create a set of generic OR classes as part of our
> foundation framework.
Please take a look at:
Alzabo (alzabo.sourceforge.net) - my own project
Tangram (www.tangram-persistence.org)
Those two are both very ambitious in terms of multiple DB support and
complete abstraction.
There are a number others that in a similar vein that are less ambitious
(IMO):
Class::DBI
DBIx::DBSchema
BingoX::Carbon
DbFramework
Those are all on CPAN. Of all of them, Tangram is by far the most mature.
It is also actively maintained. I know that the first three on the bottom
list, as well as Alzabo, are also being maintained.
-dave
/*==================
www.urth.org
We await the New Sun
==================*/