Talk:UCWCE

Request For Comments

--Nybble 22:07, 22 Feb 2006 (EST)

Looks great! but I have no idea what most of it means...

--Aurora 09:39, 23 Feb 2006 (EST)

Modules: ...but I...

Schema:

Book/Chapter -- are the chapter start/end values supposed to specify a range of comic ID's (cid)? And do the book start/end specify a range of chapter ID's (chapter)?

An alternate suggestion would be to have a chapter column in the comic table. Then the chapter table would have chapter_id, title, and book. The book table would have book_id and title. This makes sure each comic is individually linked, in case we ever, for example, take one down out of the middle and want to replace it later, or anything random that otherwise disrupts nice, neat ordering and breaks the ranges.

The other thing you might want is a status setting that would allow de-activating an individual comic (eg, working, live, expired) so we could potentially upload it in working, view it, post an initial news on it, blah blah...then the cron that launches on a specific date would just have to flip the status to live. If one ever needs to be taken down for any reason, it could be manually switched to working or expired. Whether that's worth it would depend on how likely it is for us to want that kind of preview ability or shutoff switch. It would also allow us to play with/test the system to see how everything works and looks without disrupting the actual comic site.

For the search table, I'm not sure I understand it here...is the lookup supposed to combine information from the 'type' and 'id' columns to look up based on comic.cid or news.nid?

--Ratri 14:01, 23 Feb 2006 (EST)

Ratri's live/working/expired status idea is gold. It'll help us out a lot. It'll also help us if we realize, for example, that the color of the comic clashes with the site, or there's a continuity error we didn't notice until now.

How will we measure the weights of keywords in the search field? I guess we can make simple heuristics:

In the script = high

In the title or topic = good

In quick summary of plot = OK

or something like that.

Also: We should add quick, terse summaries of plots to the keywords for each comic.

That's my two cents. --Chadius 15:59, 23 Feb 2006 (EST)

At the very least, the plan was to have the system have a https site with a password to view uncommitted comics. I suppose a status element directly in the comic table is a solution to that.

I'm considering ditching several of the tables. It seems I can have MySQL handle indexing of text for searching for me, so I don't need to implement it myself. MySQL would then handle relevancy itself. I could possibly index the columns for title and content separately to perform our own weighting, but I'm not sure if that would a have negative impact on the resulting query speeds.

The initial design of the comic table includes a field for plot summaries: "Text Description".

--Nybble 10:56, 24 Feb 2006 (EST)

Question to think about:

What happens to date (timestamp) that is placed on a news post when it is attached to a comic that is scheduled to go live at a date in the future? Should the time stamps still be set to the initial posting? Or should they be changed to the date that the comic was made live?

If you keep the old date, then it will inform your readers just how far in advance you may be working (haha...). If you use the new date, you are eliminating some of the point of this information. It also means that later posts that were attached to earlier comics could have dates that are earlier than the posting date of the entry for the new comic even though they were written in the other order. (Maybe I could write this in as a configurable option for webcomic sites.

--Nybble 00:23, 26 Feb 2006 (EST)