Wedge

We would have to rewrite every single line in order to no longer be a derivative, but it'll happen in time.

Why didn't you start from 0 and avoid this mess? I think you both have a pure clean and great workspace that both could work in.

Just a thought.

We talked about it, actually.

The honest answer is that we'd spend 6 months writing really dull code that would bore the ass off us before we got to anything fun, and knowing as we did that SMF 2.0 would open the code up, it seemed like a no-brainer.

I will note that we even talked about talking to Unknown and co to see if there was any possibility of using SMF 1's code in the event that SMF 2's was a no-go, or even just to get the rights to fork it and be done with it, on the theory of 'better that than nothing at all'.

I think we actually made the right choice; SMF isn't perfect, but it's the nearest thing out there to it, in our opinion. Why reinvent the wheel when most of the wheel isn't broken?

I think I got a good question, did you thought of using an existing MIT/BSD Licensed MVC design pattern and a database abstraction layer such as doctrine?

To implement either would be a major, major rewrite. SMF (and thus Wedge) is already tentatively MVC structured, but it could easily be more thoroughly concrete in that direction (only earlier today, there was a discussion about an idea that might have gone into SMF 3 that I am interested in pursuing that would help in that direction)

SMF's DB layering is primitive, it's designed to basically fudge MySQL queries into PostgreSQL and SQLite, well we removed most of that, but in order for us to viably use a real abstraction layer, the schema needs to be overhauled first, and need to get rid of so many FIND_IN_SET calls for matching :o (Yes, the list of secondary groups a user is in is stored as a comma separated list in the members table directly, just for an off-the-top-of-my-head example)

Pete, if you're gonna rewrite the Db structure, please do it before we even go alpha ;)

Some of the DB structure changes have already begun; board access isn't stored in the boards table any more for this reason. Membergroups is the other biggie that needs to change.

Yeah, that's why I need you to finish the structure changes ;)

BTW I have this 'aeva' field in the members table... Maybe I should rename it to something like 'options'. This is to potentially have an unused field in the DB whose sole purpose is to provide the ability to store non-searchable personal settings for members. (i.e. through serialize.) However, I don't know if it has a point or not. I mean, we could just as well store anything into the proper options table... (I just kinda like serializing stuff. It's in my blood.)

...

Like I've said before, did it not occur to you that some of these things have occurred to us?

And no, if you think putting the entire thing into a single class is a good idea, you probably misunderstood the point of objects.

texasman, when I ask this kind of technical question -- I'm usually talking to Pete. If I can't ask him a question without you coming and telling me how to do it in a better way, then I'll just ask my questions in the private area -- which I avoid doing as much as I can, because I'm a firm believer in openness about the making of a project.

Pete, you haven't answered my question :lol:

Putting it in the members table (and thus yoinking some of it out of the themes table) strikes me as generally a good idea.

Performance wise the cost is not too significant; if it were the only column in the members table that was a text column (as opposed to a varchar) I'd definitely be insisting on it being a separate table (whether that's one row per member or one row per setting per member is another matter)

Don't forget, we already have the themes table doing that, and while there's a semantic issue, it's worth remembering that for a lot of it, anything stored there for the user will be loaded automatically for them on bootstrap, so unless you have a lot of settings, it might be worth just reusing that.

serialize is good, but I've recently been hearing a few concerns about performance of it (especially compared to the json_* functions), though it's incredibly convenient for storing variable schema information (e.g. log entries that may or may not require more data than is normally available)

This Texas dude is becoming a real PIA!  :niark:

In my tests serializing/unserializing a 1.5MB array was as fast as including a file with that array, which was much faster than JSON..for some surprising reason.