Hi [EMAIL PROTECTED],
What should I do to get my module InfoSys::FreeDB in the module list?
Some people have a hard time finding it.
I also have a couple of other modules which also do not show up in
the list. I guess I must be structurally forgetting/omitting
something vital.
Ciao,
Vincenzo
khemir nadim wrote:
"Fergal Daly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
On Fri, Jan 23, 2004 at 01:36:48AM -0500, David Manura wrote:
Fergal,
I like what Version::Split is attempting to do (triggering a compile
time
error if a newer version of a module could result in logi
Fergal Daly wrote:
On Saturday 24 January 2004 18:27, David Manura wrote:
(1) All code that works with Version A will also work with subsequent Version B.
(e.g. adding new functions)
(2) There exists code that works with Version A but will not work with Version
B. (e.g. changing existing funct
Dave Rolsky wrote:
I think Simon nails this when he
talks about how Mail::Internet forces users to call something like
"$msg->head->get", etc.
yes, I agree with you. I had to search and search and search to find
what I wanted. However, had I looked at the samples directory, there was
somethin
NAME
Config::DBI - database connection support via Config::ApacheFormat files
SYNOPSIS
In .cshrc:
setenv DBI_CONF dbi.conf
In dbi.conf:
# Pass may be a password, or in which case, the password is
# is prompted for:
Pass
# Connect attribute
# dbi_connect_method is a sta
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2004-01-28 14:45]:
> What should I do to get my module InfoSys::FreeDB in the module
> list? Some people have a hard time finding it.
They'll have a much easier time finding it if you chose a better
name.
I suspect the number of people who browse CPAN usi
On Wed, 28 Jan 2004, Terrence Brannon wrote:
> >I also tend to agree with him that Mail::Box is a bit over-engineered in
> >the OO department. Do you _really_ need _eleven_ classes for
> >Mail::Message::Field, which in turn are presumably used by the _nine_
> >Mail::Message::Head classes?
> >
> m
* Dave Rolsky ([EMAIL PROTECTED]) [040126 23:58]:
> On Mon, 26 Jan 2004, Mark Overmeer wrote:
> > > >- Not so great API. The API isn't so bad that I'd call it awful,
> > > > but it's inelegant and bulky, and definitely doesn't make
> > > > simple things simple.
> > Depends what you have read.
* Terrence Brannon ([EMAIL PROTECTED]) [040128 08:58]:
> >And even if you really do need them, is this something that the end user
> >needs to be exposed to?
>
> yes, that's a good point. How to write docs for the developer of the
> code versus someone that wants to make common use of it. Mason h
> grepmail : "grep" program for mailboxes. Currently only supports mbox
> format.
>
> Not sure about the last one. Do/can we register namespaces for scripts?
what about "grepmbox" instead? you can always go to grepmail when you
support other formats (like mail spool for instance)
Cheers,Nadi
Title: RE: New module Mail::SendEasy
> But my point is not to rag on about Mail::Box, or any other
> mail handling
> module. It's to write smaller, cleaner, single purpose ones.
> Hey, Email::MIME
> came out the other day. Comments welcome.
Ill have a look at some point. It will be interes
Sorry, I'm not on the list, but got this passed on...
> >Date: Mon, 26 Jan 2004 13:49:29 -0600 (CST)
> >Subject: Re: New module Mail::SendEasy
> >
> >On Mon, 26 Jan 2004, Simon Cozens wrote:
> >
> >> [EMAIL PROTECTED] (Yves Orton) writes:
> >> > Besides this is there really any reason for yet a
On Wed, 28 Jan 2004, Terrence Brannon wrote:
> - it seems that instead of volunteers to ease the burden of your API
> usage/docs, people are trying to pull the rug out from under you by
> populating the Email::* hierarchy... oh well.
I hope you're not including me here. My comments were intended
On Wednesday 28 January 2004 05:28, David Manura wrote:
> I'm not sure branching maps cleanly onto the interface versioning scheme as
> shown above. Let's say you have 1.2. You then branch to 1.2.1.1 => 1.2.
> Meanwhile, in your main trunk, you create 1.3 => 1.2. OK, now back in the
> branch,
Mark Overmeer wrote:
Mail::Box was designed to start with EVERYTHING which the RFCs specify,
and ALL uses I know with e-mail. A very high level library. And that's
quite a lot... And therefore suffers all the same problems as other
large modules (like Tk) have: they are hard to understand when y
Phew... Only one comment: KISS (Keep It Simple Stupid)
This is WAY too confusing! No one will be able to figure it out, or
want to. What we have now is not really that broken, especially if one
regression tests his applications when new versions of modules are
installed.
Actually, we build o
At 02:12 -0600 1/28/04, Dave Rolsky wrote:
On Wed, 28 Jan 2004, Terrence Brannon wrote:
> >I also tend to agree with him that Mail::Box is a bit over-engineered in
>the OO department. Do you _really_ need _eleven_ classes for
>Mail::Message::Field, which in turn are presumably used by the _nine
disposing of the interface number in the distribution name
is that a module might implement multiple versions of an interface, and, second,
the interface number is redundant: under my scheme the interface number can be
deduced from the implementation number upon examining the module. The second
po
On Wed, 28 Jan 2004, Elizabeth Mattijsen wrote:
> At 02:12 -0600 1/28/04, Dave Rolsky wrote:
> >On Wed, 28 Jan 2004, Terrence Brannon wrote:
> > > >I also tend to agree with him that Mail::Box is a bit over-engineered in
> >> >the OO department. Do you _really_ need _eleven_ classes for
> >> >
Mark Overmeer wrote:
OTOH, it _does_ do basically everything you'd ever want for mail
handling/sending, and if you want to do something complex, it'll do that
that.
That is one of the differences in concept. I prefer libraries to provide
a high leve
20 matches
Mail list logo
