Wish List
(For once, something that really belongs in the “wishful thinking” category…)
Some more discussion around the family dinner table involved family members with a tendency to get an early start on Christmas shopping. (I thought I was being harried by aunts at Thanksgiving, but when my sister-in-law asks about my list at Thanksgiving, it’s because I’m the last one she hasn’t checked off her list. I have to admit I’m a bit jealous.)
One thing we discussed was the possibility of creating a sort of on-line family registry. The idea is that family members would each be able to post a list. Then other family members would be able to not only read the list, but mark things off to avoid duplicates. So far, so Amazon.com, but the catch which I want to apply is more Christmasy: I don’t want the list owner to be able to see what, if anything, has been marked off their list. (I’m all about the surprises under the wrapping.) A. also suggested that others should be able to put items on others’ lists, so (as an example) if someone was getting charts, that could spark waterproof chart bags, or something like that. So there’s a rough idea of your feature set.
Following the great dictum about hammers and nails (“When the only tool you have is a hammer…”) I immediately started thinking of it as a MySQL/PHP application. I’d need to authenticate all users, because I’d need to do access control based on what username they auth with. I allow each login ownership of a list. (Maybe I’d need some way of managing lists for minors, i.e. The Pink Ladies.) So there’s one table: users and user data. And a small collection of forms-and-applications for auth, password creation, alteration and retrieval, etc. etc. Users can add items to the lists, so there’s another table: items. Relationship to user (the gift recipient) and creator, because when the user is also the recipient, there will have to be controls over what they can see and edit. They can’t see items others have created with them as recipient; they can’t see status of items they created with them as recipient. Items have titles, brief descriptions, maybe URLs, maybe images? (We’d need forms to upload image files.) Suggested sources, perhaps. We need to allow for both catalog-circlers and those who try to stay vague and inspire serendipity.
We’d need a mechanism for changing the status of an item.
The only thing I can’t map out in my head is the final trick: as the database owner, I would be able to look in the database and see status on everything—essentially, since I create the access control, I can also bypass it. I’m trying to figure out some way that I can store status such that the database owner can’t check it—it can only be read through the relevant PHP application. I’m thinking about using a unique hash for each item (maybe I hash the title?) and then deliberately scramble the hash when the status changes… but no, if I can figure out a way to check it with the application, I could write another application that bypasses the access control and gets it back out.
Maybe I need to apply public-key encryption and force my users to generate keys. I’m probably thinking about this too much anyway, because I suspect there would be enough people in the family who wouldn’t use it, or would constantly forget their password, or would ask [insert other family member here] to remember their password for them…
Ideas? Anyone?
Comments
Posted by: Andy B | October 24, 2004 10:21 PM
Also, when you’re done I’d like to steal this app and apply it to an idea I had… tracking peoples collections of things. Many people collect things but if you try to buy them something that they collect you would need to know which items in the collection they already have, and possibly which items have already been purchased by someone else (gifts-pending). For example, if someone collected those little wooden light houses with the little black cat…
Posted by: commentor | December 6, 2004 12:50 PM