/*

db sketch for photoblog ... again
this time simpler
manage posts, not photos

Why the change to post-based?

Because a full image metadata system would be awful tricky. I want some experience here before I try it.

Still tricky.

backend == postgres?

Yes. Deviations from postgres here (e.g., I think I'm using "date" where it should be "datetime"; I'm using id as a shorthand for an acutual id declaration, etc.) will eventually be f1xx0red. This is more just to list the stuff I really must be keeping track of.

*/

create table comments {
	id;
	date;
	text author; // actually, this too	Right. Comment author, not post author? Yes.
	text authormail;// will these be on every post? No. These are both optional.
	text authorsite; // this one being one of the both
	bool okayed; // ?
	// I also kind of want comments to be editable, because I hate it when I notice I posted a typo to someone else's site, but without logins that just makes it a wiki. Although.... You're thinking name-optional anonymous public commenting, then? Yes. On the other hand, I'm already going to have to have a login system for management.
	//For the really swooft setup: moderated comments, with an automated email address to request typo corrections. That would be nice. Obviously, in a threaded discussion (even if it's technically linear, with references), there's a sort of integrity issue if you let people edit. If I say "the holocaust was bad" and someone says "re: holocaust, you're right", and I s/bad/good/, that's bad. Sticky!
}

create table users {
	id;
	text name;
	text uri;
	text email;
	text usercss;//++.
	// I really want it customizable. Maybe even user javascript.
	// Maybe I shoulodn't talk about this, in hopes it'll make me do it, but:
	// I want a fairly crowded, note-heavy look when the cursor's over the page. Even a background-color slider system (maybe with L*a*b* (NEEEERRD!)). But when the cursor's off, display:none for everything but the pictures.
	// I'm sick of photoblogs that have too much (hard to look at the actual pitcher) or too little (I want a link for "previous" other than the currect pitcher, you know).
	//Yeah. I can only look at <prevthumb> <bigcurrent> <nextthumb> so many times.
	// I'm wondering about thumbnails just for archives. I don't have a plan for archives at all now.
	// One cute system the Linuxart people (I think?) were using was [click on left side of photo] = back, [click on top of photo] = up to archive, [click in middle] = zoom in, etc. Really hard to learn by trial and error, but then extremely pleasant.
	//Maybe I'm suffering from links-are-blue syndrome, but I do like the click-anywhere-on-the-photo-for-large-size theory.
	// Here's the thing ... I don't want to put the large version in a pop-up. And if I'm putting it on a real page, I'm going to want the navigation links still there. And if I'm going to navigate from it, I want the large versions of the other pictures too. So it becomes a site-wide big-version mode. And then I wonder why not to just make that the default. (1) To save bandwidth, (2) because large might be too large to fit on a reasonable page.(Yeah. It was a horrible moment when I realized that I couldn't live with cropping anymore because I assumed by default that I could scroll to see more of the image.)
//One mode everywhere does make sense.
	// So, furthermore, what's a reasonable size? Right now, I've been using 600px on the long side or 450*450, whichever is smaller. I usually stay between 50 and 100kB. Seems reasonable. I'm thinking maybe a bit bigger -- 800, or 600*600, say. Just not sure. It probably should be consistent.Especially if there's navigation sutff that could move when the picture size changes. I hate trying to click through a large gallery that requires a 10-px cursor movement every time. Absolutely. On the other hand, some things are small by nature (e.g., at the zoom limit), and some large (panoramas). Maybe a limited big-mode is a good idea.Make it a high threshold, so you only use it when you really need it. Check. Also, it may be avoidable by putting the nav where it doesn't get resized.

   title
[         ] I like 'em here when the photo's big enough that I might need to resized my usual tiny little browser window. It does seem like a natural place to put your hand relative to a physical object, too. In fact, the centeredness seems tricky to me. Yeah. think of the 800x600 monitors of the universe. And yet I don't want to. Not for this. Nor for the buggy CSS and JavaScript support. Have a link to the raw directory listing and let 'em do what they want. Yeah.
[ picture ] -?>
[         ]
  <- ^ ->


}

create table userstocomments {
	user refers to users[id];
	comment refers to comments[id];
}

create table commentstoposts {
	comment refers to comments[id];
	post refers to posts[id];
}

create table posts {
	id;
	text about;
	text title;
	text shorttitle;
	date startshowing;
	bool acceptcomments; // ?
}

create table poststophotos {
	photo refers to photos[id];
	post refers to posts[id];
	float precedence;
}

create table photos {
	id;
	text URI;
	date timetaken;
	text wheretaken;
	text technotes;// I think it should be easy enough to dump the individual photo metadata here once you have the system going.
	// Yes, but. (1) A post can have several photos. (2) I want natural-language stuff ("I had to hang by my feet from the railing and hold the camera upside-down") as well as EXIF. (These are notes, not objections.)
	// How long until EXIF has an in-camera "notes" field?
	// I'm sure it has free fields already; now all we need is a firmware with a text-entry keypad. Whee! Mmm, SMS. Ow, my thumb. Many cameras now, even relatively low-end ones, have a voice note feature. I find it easier to write these things on a bit of paper.Yeah, well.
	
	text about; // i.e., subject
	bool materialmod;
}

create table posttags {
	post refers to posts[id];
	tag refers to tags[id];
}

create table tags