[pmwiki-devel] database tools and hacks in PmWiki

[Crisses]

On Dec 10, 2006, at 1:34 AM, Ben Wilson wrote:

> I believe Crisses (Xes) is working on a database library for PmWiki
> based in ADODB as well. I You may wish to work with her to combine
> effort. I regret I've been sort of out of the loop since about
> October, so I'm not sure of her level of effort or production.
> However, it appears I'm coming back in the loop; sort of.
>
> Regards,
> Ben

I'm not working on a database library -- not that I know of.  I was  
going to work on a generic script for database recipes to use -- you  
got to it before me, and I was very happy.  I have at least 12+  
PmWiki projects upcoming.

Some items on my list may never happen, if the paid projects behind  
them don't go live.  Some are pet projects - no one has approached me  
to do them, I just WANT to do them.  Many may use ZAP for part or all  
of the features.

  * distance by zip code calculator - not a Google map api -- client  
wants to NOT give away location under certain circumstances, just  
entice paying subscribers by saying how many listings there are on  
the site, and how far away they are.
  * improved events calendar - perhaps integrating the iCalendar  
format (iCalendar portion is pet project, the rest is client proposal)
  * paid (PayPal) subscriptions tied into the AuthUserDBase  
authentication -> changes what group people are under, which changes  
their privileges on the site.
  * change page ratings recipe to include aye/nay/abstain for  
official group proposals, maybe add multiple "vote" ability per page?  
(pet project)
  * shopping cart system (and some shipping/payment modules) - this  
is the farthest out because it's most complex (pet project).
  * obscured downloads -> so people may buy items, or download  
documents without being able to give out their URL location (pet  
project)
  * expiration for pages -> some way for pages or data stored on  
pages to "expire" either by moving to a restricted group or using the  
PmWiki delete command on a certain date
  * email-to-wiki (discussed previously on list - pet project)
  * expand the business directory I created yesterday - need to add  
categories, a way to bump certain listings to the top of the list,  
and so on -- may use the vCard format
  * classified ads (one place the page/data expirations comes in)
  * method of easy moderator approval for pages/listings/data, etc.  
(a link or button on the page that changes the read password?  I  
don't care, it just has to be quick & easy -- not adding ?action=attr  
to the toolbar and changing something to "@nopass" -- think "I don't  
have time for this" or "That's too much to remember")  Also needs to  
come with a method of listing items that need to be approved, of course!
  * private messaging - would act a bit like webmail
  * newsletter subscription double-opt-in manager (may tie in koops  
mailing list, change it to use flat-files?)

I'll go update my profile page -- I have been keeping an "upcoming"  
list there if anyone is interested in how busy I am or wants to  
volunteer to do something on my list, help with something, or offer a  
bounty so that I work on something NOW instead of whenever.

So, on the "database library" that you thought I was building:  I  
will be working on a couple add-ins for AuthUserDBase (admin panel &  
group management too!). I think keeping users' private information in  
a database is pretty important, but I LOVE the PmWiki flat-file  
system for many reasons.  So I will be sticking with flat-file as  
much as I can in my recipes, even though I look forward to seeing  
other people's wonderful database recipes.

I have thought through the product/service end of the shopping cart,  
but not the order storage end.  Storing credit card/bank information  
in flat files is absolutely out of the question for me, one reason I  
love PayPal from a liability/programming point of view -- absolutely  
no need to store financial information on the system.  The moment the  
shopping cart system requires working with other merchant processing  
systems that require the shopping cart to handle sensitive financial  
information, we're entering very mucky territory in the way PmWiki  
handles data.  You must store the customer's credit card in case of a  
product return, or needing to issue a credit, etc.  But you can't  
store it in a text file.  You can't one-way encrypt it.  Do we use  
GPG?  That doesn't work, because the web server would need access to  
the keys.  It's a pain, and so far a database is the best answer I  
have.  I personally prefer to stick with a service like PayPal  
because I don't want the liability.

I hope that helps people understand exactly where I'm at, and what  
I'm doing with my PmWiki-time.  You're not stepping on my toes if you  
work on *anything* currently available in PmWiki.  Just let me know  
if it might break AuthUserDBase :)  If you update the  
DatabaseStandard or AuthUserDBase pages/scripts, I'll be notified by  
email, so go for it.  I will be grateful!

Crisses