Wedge

Okay... Which one?

The left one is relatively 'definitive'... The right one is still only the mockup -- I don't have the tools/skills to make it perfect.

I'd like to get the big majority of our feature list to reach 99% or more before I even think of doing something other than programming... ;)

What I like about lowercase is that it's non-aggressive... Friendlier than uppercase.

Okay since the mockup isn't very successful, I've resorted to adding a white shadow behind the original logo.
I find it still barely readable... And adding a bigger glow will make it look silly.

<PRV>....... And of course, for the rest of us, there's the Pirate Bay, torrentz.com, demonoid.com and so on. (I rarely go to demonoid, but yesterday the HD episode was only over there, not anywhere else I could think of.)

All right then. Will watch tomorrow.

I'm growing unsatisfied with the current logo. Although it's really good, I wanted to try for more simplicity in terms of shades. I used the opportunity to give a try to PT Sans, a current favorite of mine, and just build upon that with a strike-through line (similar to what Bloc suggested but applied to the entire width), and again two different colors, but this time across the entire logo, rather than on the 'w'.

What do you think?
It's only a MOCKUP, it's not something 'definitive', I'm just trying to explore other ways of showing the logo...

:edit: I'm not saying I like it best. It simply fixes my current issues with the letter 'd' in our official logo, as well as with the shades of green on the letter 'g' (it's too bright compared to the rest). Also, the new logo is optimized for dark backgrounds. Its dark background could even be part of the logo, I don't know...

I was always sure joins were faster than comma crap in all versions of Mysql?

Yes and no.
I think it would be a strain on performance if any 'virtual object' could be a floating topic.
So, an id_msg won't be floating by itself -- only a topic can be floating.
If you mean by that that we should store the parent id_msg for any message, this can be done independently -- and is something I'm considering to do, although it wouldn't be used in Wedge at all since I've long given up on nested threads (I discussed it countless times on sm.org and here I believe. I had an implementation and all. Even Wedge.org keeps storing the parent ID I believe...)Pretty much.
Now, what matters here is that, not only can the wedge_messages table be thrust into any floating element, but we can also add other items to benefit them. Like/dislike, tags, and custom fields come to mind. We'd... Just need to store the wedge_type (or something like that) for the extra entries, just in case we need to filter the entries by wedge type.I don't really see how. It's just a matter of adding an extra field with proper indexing ;)
Maybe we'll simply rename some fields internally -- although it can be done without, after all I don't mind the idea that a 'topic' can be a 'media item'... It's a topic of discussion after all. Anyway!Can you elaborate on this?