On Thu, 6 Jan 2005, Scott W Gifford wrote:
If the user has custom data, they would just install Geo::PostalCode
and build their own database (it includes a short script to do this,
and the process takes about 2 minutes). Geo::PostalCode::US doesn't
replace Geo::PostalCode, but just adds a
On Thu, 6 Jan 2005, Chris Josephes wrote:
2. Include a make install-data target that will unzip the data, and then
install it in a standard location your module will search by default.
Would /usr/share/postal/us be a bad place? Is anyone else doing this?
As a quick follow-up to my own post
On Tue, 4 Jan 2005, Scott W Gifford wrote:
The advantages of having the data on CPAN is that the entire module is
self-sufficient and widely mirrored. It makes it much easier to
install, and if you have a CPAN distribution on CD or in a local
mirror, you have everything you need. The
On Tue, 7 Dec 2004, Christopher Hicks wrote:
I don't care about Oracle or any of the rest. Making this work with PG
and MySQL will solve 90% of the world's problems. I don't see why it
couldn't be extended to include whatever parameters where necessary for
any of the proprietary databases,
How does the code check the integrity of the file? I mean, is there any
hardware/driver code thrown in here? Is it specific for systems using
SATA controllers?? That might affect namespace ideas.
I liked the File::Integrity suggestion, but I'd want to know more.
On Sun, 17 Oct 2004, Joshua
So, if I want to write a review of Net::SMTP, I'd do the following.
1. Use Module::Build, or ExtUtils::MakeMaker to create
Review::Net::SMTP::CHRISJ, or whatever.
2. Make sure I have my README.txt, CHANGES, and MANIFEST file.
3. Write my review in POD format, and throw in some META.yml indexing
On Thu, 22 Jul 2004, Ken Williams wrote:
I was sort of hoping this idea would just die on its own, but now it
looks like people are actually getting ready to do it. In my opinion
this is a bad idea. I don't want a bunch of reviews all over CPAN
disguising themselves as modules. I also
What about WWW::Service::Map???
That would seem to fit.
On Fri, 9 Jul 2004, Dave Rolsky wrote:
On Fri, 9 Jul 2004, David Wheeler wrote:
On Jul 9, 2004, at 3:43 PM, Dave Rolsky wrote:
This'd be great _except_ that www.maplink.com is the website for a
map/travel book company. Too
I'm 50/50 on this.
Just because a module name mentions Javascript doesn't mean it would
immediately be discounted by other developers. If people need something
to handle Tooltips, they'll use it, or at least read the pod
documentation.
Also, there are lots of other tooltip implementations out
On Wed, 16 Jun 2004, Fergal Daly wrote:
On Wed, Jun 16, 2004 at 06:39:22PM -0300, SilvioCVdeAlmeida wrote:
Let's write it better:
1. FORBID any module without a meaningful readme with all its (possibly
recursive) dependencies, its pod and any other relevant information
inside.
Having
On Wed, 16 Jun 2004, Mark Stosberg wrote:
Another perspective: I do see signs that the current rating system is
helping. After receiving several negative ratings, CGI::NeedSSL has been
pulled from CPAN.
What was the deal with this? I never used the module, I was just curious
about what
On Mon, 19 Jan 2004, Daniel Staal wrote:
Basically, adding the author's name into the name of the module just
trades an illusion of a 'clean' TLD for my headspace. I would rather
have a messy TLD: there are tools that can help me search and sort
that. Perl is *supposed* to help me clean my
On Fri, 3 Jan 2003, Jay Lawrence wrote:
And yeh, upon writing this it makes sense to move them up. The
Business::vFile module remains as the base class, but I will rename the
others to : Business::vCalendar vs. Business::vFile::vCalendar.
One good thing about Business::vFile would be you
On Tue, 15 Oct 2002, Terrence Brannon wrote:
Chris 2. The template language should not follow Perl syntax rules,
Chris or be designed with preference towards Perl users or
Chris programmers.
1. developing a good language is very difficult.
I didn't mean to necessarily infer the
On 15 Oct 2002, William R Ward wrote:
For me, it's because TT allows Perl to be embedded in the template.
That way lies madness. The advantage of a templating system is that
you can leave the template maintenance to someone who doesn't know
programming, and let the programmer focus on the
On Mon, 14 Oct 2002, Andy Wardley wrote:
Chris Josephes wrote:
2. Text::MetaText
[...]
...but it has a very limited command set with no means
to allow for expansion.
... and has been superceded by the Template Toolkit.
Oops. Sorry about that. I should have pointed that out
On Mon, 14 Oct 2002, David Kaufman wrote:
the way to avoid your two concerns (permissions and support) is to
participate in the community, join the mailing list of the system you like
best, and would want to contribute to, listen a while, and suggest your
changes. most likely they will be
On Sat, 12 Oct 2002, Leon Brocard wrote:
Chris Josephes sent the following bits through the ether:
Given the high number of template systems out there, it is easy to
understand the reluctance or hesitation in adding another one to
CPAN.
Everyone seems to write their own template
errors that it needs to deal
with.
AUTHOR
Chris Josephes [EMAIL PROTECTED]
SEE ALSO
the Text::UberText::Tree manpage, the Text::UberText::Dispatch
manpage, the Text::UberText::Parser manpage
COPYRIGHT
Copyright 2002, Chris Josephes. All rights reserved. This module
is free
19 matches
Mail list logo
