Wedge

As discussed earlier, I'm spending some time with the database and trying to harmonize field sizes.

id_album is currenty an int(10), while id_board is smallint(5).
In the future, albums will internally be treated as boards, so I could either reduce the id_album to a smallint (maximum value: unsigned 64K), or increase the size of id_board to medium(8), i.e. in the millions, and reduce the size of id_album accordingly.

While technically it's true that having millions of boards will probably crash Wedge before long, I'm not sure that the 64K limit is good enough. If you have a popular website where thousands of users create media galleries every day, you could easily break the limit in a few months time. More realistically, any image-oriented forum with a decent community could potentially break the limit in a few years. After that, we can either release a patch to increase the id_board size for them -- or simply account for it now.

Only problem is, mediumint(8) is stored on 3 bytes so I'm not sure it's as good in terms of performance as smallint. What do you think...? (The worst possible offender is the messages table, which has an id_board field.)

And finally -- id_group should be increased as well. Currently it's set to mediumint(5) which doesn't make sense (the 5-char limit will likely be ignored anyway if there are millions of groups...?), so I started by setting it to mediumint(8) for clarity, and then changed it to int(10) mainly for one reason: ideally, ANY user can create ANY number of groups to put ANY number of members into it. We should (?) probably put a limit to those, but for now I'm upgrading to int. Anyone knows whether this will have an influence over perfs...?

So... For the last few weeks I've been considering multiple ways of integrating media items smoothly into Wedge. (Via the upcoming floating board feature.)

After all this time, there's one technique that sticks, and I'll explain it to you. The reason is that I'm not sure whether it's for the best, because it has a few disadvantages.

Simply said, a topic (wedge_topics table) would now have an associated id_media field. This field would represent a single entry in the media table.
With that said:

- an album is a custom board
- an album comment thread is a topic in this board where id_media = 0 (no associated image)
- an album item is actually a topic, which has a custom id_media that tells Wedge what thumbnail it should show. The item description could very simply be the first post in the topic.
- an album item comment thread is, obviously, the list of messages in that topic.

One of the advantages of this system is that it allows you to associate a media item with a topic even when the board isn't an album board.
For instance, we could have a blog where the posts are listed along with a thumbnail of their associated media item. Meaning, for each blog post the first media item you upload for it will become the default id_media for the topic. I could also ensure that you can select another item for use as main item. (Really, you could even use a single id_media for multiple blog posts -- e.g. like a category image.)

Now for the drawbacks...
- when you're writing a post, even a reply to some other post, if you upload a media item to attach in it, it creates a new topic internally. Which makes a lot of sense -- but then you get to the point where creating topics as 'supporting players' of a simple message sounds weird, even uncomfortable. (Then again, it's only internal stuff. I mean, users of Facebook don't really mind URLs with long series of digits... Also, we could always show ?topic=base64encoded_id in the URL, ahah...)
- it's not gonna be fun writing a converter for all of that... (Plus, TE is kinda MIA these days, so I fear it will be up to me to do it :P)
- the 'view unseen' permission is nulled by this, because it's all about new topics by then. Maybe I could add a filter for board types in the 'view unread posts' page. i.e. 'Mark (select box) as read' where the select box has Forums, Media, Blogs...
- I had another drawback in mind, which actually brought me to write this post, but I forgot about it for now. I'll make sure to bump this topic if I remember it.

Also, I've noticed that in AeMe, id_media is set to a size of int(11), while topics are set to mediumint(8). If a topic is now automatically attached to a media item, then it makes sense to set topics to int(11) as well, or set media size to mediumint(8) instead... No?

Which also reminds me that the SQL file has a lot of entries that don't use UNSIGNED where they could. But I don't know what's best -- fixing them as I find them, or leaving them as is, in the event that some would actually want to force a negative value...? (see privacy levels for instance, where a value of -3 means 'everyone' so that positive values can be assigned to membergroups.)

Please discuss all of this :)

(And Pete -- I understand you're on your way to KY, so you're dismissed, I was myself totally unable to participate in complex discussions this week with all the jetlag :P But if there aren't any solutions found by the time you come back, please feel free to share your opinion!)

Sadly ----- agreed strongly.

FB hosts the whole image doesn't it...?

And AeMe offers to host images remotely, too, thus ensuring this could happen.
OTOH, preventing this could be annoying, i.e. signatures with a banner that shows up details that depend on a cookie being set... That could annoy some people if it got messed up.

There's now a 24-hour window for editing posts... Isn't it enough...?

I need a briefing on this. I still don't know what's best -- deleting replace-type skins or not.

So... What about these? Anyone happy or unhappy with them?
(Of course, to test these you need to touch the database manually... Sorry about that.)