There's been a lot of really groovy ideas for new features which are a ways out there -- "maybe someday" expansions to the basic journaling functionality we have today on LJ, and half-baked functionality we already have on LJ which needs some more time in the oven. It dawned on me that there was an architectural approach which might greatly enhance rolling out such features. (Perhaps this is old news. And maybe this idea sucks.)
Consider if there were a foreign key field on the posts table, named "type" (or whatever), which indicated which "type" of object a row is. "1" would presumably be "journal post". But then you could have "2" be "market-place ad" (alluding to Denise's idea); it would show both in the "market-place" and (optional user set preference) in the poster's own journal. Or maybe 2 is "calender entry", where, if it's well formed in calender entry format, it's picked up by the calender module and shown as an event. By format, something simple like the way post-by-email works to take metadata. Using XMLish solutions the way Polls do is probably overkill. Memories could be handled this way (if they aren't already). Possibly also to-dos. Theoretically so could Suggestions and Support requests -- thought that actually has special architectural/performance concerns (as does the marketplace and anything which aggregates content across multiple journals). Because it's a foreign key field, as new systems were thought up, they wouldn't need new db tables, just a new line on the "type" table -- and a format protocol for within posts, which might be handled entirely by the interface so the user doesn't have to learn it. People closer to the code than I would know if this is a terrible idea or not. It's not a typical approach, so I thought I'd mention it. -- Siderea _______________________________________________ dw-discuss mailing list [email protected] http://lists.dwscoalition.org/cgi-bin/mailman/listinfo/dw-discuss
