> WebDragon wrote:
> > I'm curious to know if there are any generic call-response subscribe
> > packages out there written in Perl (preferably object oriented in
design)
> >
> > i.e. what I am looking for is,
> > {
> > o user subscribes via form on website, gives e-mail address and
> > creates a password
> >
> > o user is sent a 'call' e-mail saying "you've just been
subscribed.
> > did you want this? if so, click this URL"
> >
> > o clicking the URL 'response' finishes the subscription process,
> > and users data is then sent onward. user recieves a confirmation
message
> > as a result of their webclick both in the webpage itself and via
e-mail,
> > thanking them for joining.
> >
> > o eventually something is done to clean up the data for which
there
> > was no further 'response'.
> > }
> >
> > I would like to have such a feature as part of a package I'm writing
for
> > this client, rather than just blindly accept the data and their choice
> > of e-mail. That and I really hate to have to re-invent the wheel if
> > something suitable is already available for use that has worked around
> > some of the obvious problems involved with this issue.
> >
> > There are several open source packages out there that implement such
> > things but it is rarely something semi-separate from the package itself
> > that can be easily extracted, genericised, and put to use elsewhere. I
> > would prefer something that is 'the thing itself' and easily integrated
> > further into whatever needs it. (rather than spending a few weeks
> > stripping it out of whatever package I find that does it well enough to
> > suit my needs, and refactoring it. ack! :)
> >
> > If anyone has any information leading to such a thing, I would be most
> > grateful. Surely someone has done this by now?
>
> never saw a response to this, so I'm reposting once in the hopes that
> perhaps someone else will see it that has any recommendations.
>
> --
> Scott R. Godin
> Laughing Dragon Services
> www.webdragon.net
>
I somewhat suspect not. The problem is that having this generic would be
rather difficult to design, for several reasons. How do you store the
data? Database, flat text, sendmail alias file, xml, or process it some
other way. How are the pages being generated? CGI, mod_perl. Are the
pages templated, what template language to use if so, if not are they
static, do they come in only one language, how many languages does the
site use? Depending on how the pages are generated (see above)
determines a lot about what URLs have to look like. Then there is the
whole range of session management, how do you link up a subscription
e-mail with the data store? What e-mail server is installed, are the
required mail modules installed? Then there are the hundreds of other
options available, aka are there separate subscription models, are the
passwords clear or encrypted, is there a tool to retrieve/reset
passwords, etc. All of this contributes to creating a framework that is
daunting, and likely slow and bulky to accomodate so many different
options. At that point you are better off heading in one of two
directions, using a prebuilt framework for the site itself, or
reinventing the wheel (and I do *NOT* say this lightly).
But I could be wrong...
http://danconia.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
