[pmwiki-users] Request input on soon-coming FAST Data release

The Editor editor at fast.st
Thu Oct 5 10:46:50 CDT 2006

On 10/5/06, Ben Stallings <Ben at interdependentweb.com> wrote:
> Wow!  A lot of traffic on the list since yesterday evening.
> Caveman, thanks for asking for suggestions.  For what it's worth I
> second all of Chrisses's suggestions: spin off optional functions into
> separate files that are included as needed; provide more documentation
> both in the Cookbook and in the PHP code itself; and think some more
> about the ZipData name.
> The reason I have misgivings about "ZipData" -- and I guess I'm on the
> name-approval committee ;-) -- is that if your recipe has multiple
> files, the most likely way you'll distribute them will be in a .zip
> file, hence Chrisses's comment about admins "unzipping" the file before
> uploading it to the server.  Back in my tech-support days I literally
> spent hours explaining to users the difference between a Zip disk and a
> .zip file.  Fortunately Zip disks are largely irrelevant now, but .zip
> files are still with us, and I wouldn't wish that particular problem on
> anyone when there are so many other names available.  :-)

This is a good point.  I guess they could download zip.zip.  Hehehe.

> My favorite name suggestion I've heard so far is DataPage -- it's
> catchy, descriptive, and you're already talking about data pages in the
> documentation.  So there are my two cents.

This is good, but I do want something I can talk on to multiple
cookbook recipes, like zipMessaging, zipForums, zipBlog, etc.  As the
next stage of development will be providing better support for
specific applications.

> Thanks again for asking, and best wishes for the new version!  --Ben S.

Appreciate it!  It's coming along very nicely.

FWIW, I think I have found (thanks to Pm's help) a powerful way to
address your concern about forged headers. I'm not a hacker, but the
new recipe will be about as secure as it is possible to make
it--thanks to a few clever lines that involve session cookies,
passwords, and random number generation. (Pm--do you have the final
word yet on my implementation of your suggestions?)

Actually I've added several security options that allow for
restricting uses to passwords, or to id's.  Or to ban and approve
lists.  And should be able to set attributes on pages/group config
files. Also optional protection to prevent directives from being
entered into forms.  There will be a whole section on security in the
next round of docs outlining the various security features available
in 3.0.

Other changes:  native support for the new text variable options.
Finally solved and fixed the apostrophe problem, correctly this time.
Better page formatting, and use of UpdatePage.  Plus a (:log:)
directive for easier use of the recipe's commenting features.  Still
waiting to see how Pm's commenting will compare...

Now Ben, if I've met your three conditions, we might could talk a bit
more about adding database capabilities.  Or interfacing this recipe
with your database project?  How should it look?

I'm thinking either hooks (somehow) to enable my recipe serve as a
front end for your recipe, so it can manage the input and output of
data, but your recipe does the actual database work. The other option,
might be to keep them separate but enable my recipe to do simple
database saves/queries in a format that works with what you are doing.
 Unfortunately I'm not familiar enough with your project to know what
it does/does not do, or how best these two can interface.  Maybe
someone familiar with both can comment.

Basically we should maintain separateness (as mine is designed for
those that don't want a database, and yours for those who do).  But
they should be able to work together as closely as possible.  Congrats
on the progress I see you are making.


More information about the pmwiki-users mailing list