The new forums will be named Coin Return (based on the most recent vote)! You can check on the status and timeline of the transition to the new forums here.
The Guiding Principles and New Rules document is now in effect.
Made a post in the gloss thread and ended up with 2 spoilers with only 1 tag, don't know if this is intentional, happened with an oddly placed color tag it seems
Example
Example
It happens if the tags are layered
Color start
Spoiler start
Color end
spoiler end
but not if you move either the end spoiler to the same line as the end color, or the spoiler start on to a line above the color start.
as far as I know this is a trivial bug and might even be working as intended. But i found it odd.
Having the opening of one tag in the open and close of another will send a browser's rendering engine in to a panic (called "quirks mode"), but they'll mostly put up with it and try to figure out what you meant. It looks like vB isn't so lenient.
Thanks for the report MKR. I looked at the parser code for vB, got scared, and then ran away. It might be trivial to fix, but my PHP / vB-fu is weaker than it was.
Just from the feature set, it seems like this install is highly customized, which would make most mods to the code a lot more than a plug and play adjustment.
Yeah, we have customized a lot of things to work for us feature-wise as well as some performance tweaks. vB as a platform leaves me in an interesting position. vB4 is bloatware, and my tests show it won't work for us. vB3's future support is... uncertain.
Didn't you say a while back that you were working on your own forum software in python before the old one got hacked?
It's nothing more than a proof of concept at this point, but, yes. I have it written to run on our own gear, but I've also toyed with the idea of running it on Google App Engine. We would be at the mercy of Google's infrastructure, but it would cut down the operations overhead considerably
I've also looked at Microsoft's AppFabric/Azure cloud, but it has a higher cost for a lot of features I'm not sure we need on the forums. Ironically, the one thing that Microsoft does better than GAE is full text searching. Go figure.
I'm drifting off topic. If there are enough web devs interested in a thread, I would happily move this discussion to HA or the Tech forum.
I'd take the rare App Engine downtime over search rate limiting and semi-routine DB errors. They do maintenance, but you can detect that in code and go in to read-only mode.
Can you write DB wrappers so you can switch to another solution if App Engine proves problematic? I've never done anything more complicated than a half-functioning little CMS on it, so I don't know how hard that is at this kind of scale.
edit: It could go in the programming thread over in the tavern
I'd take the rare App Engine downtime over search rate limiting and semi-routine DB errors. They do maintenance, but you can detect that in code and go in to read-only mode.
Can you write DB wrappers so you can switch to another solution if App Engine proves problematic? I've never done anything more complicated than a half-functioning little CMS on it, so I don't know how hard that is at this kind of scale.
I could use django-nonrel or something similar, but I'm not sure I want the full overhead of Django. I think to really tune the application for performance would require using a lot of GAE specific APIs / frameworks. I think that just breaking it into MVC will abstract things enough that it could be re-used later.
The main question I have is concurrency of inserts. I need to learn explore entity groups a bit more as it relates to datastore contention.
Right now, I debate between having one entity group per thread vs a "flat" approach.
A thread entity group would allow transactional updating of a thread and a post at the same time. This breaks down under two scenarios:
1) Really popular threads that receive more than 3-5 writes / second.
Solution: None. However, any errors would be contained to the thread.
2) Merging a thread into another / splitting a thread into two threads
Solution: None. A workaround would be to create new entities on the new thread and delete the old thread. In cases where over 500 posts would change threads, the process might be slow.
Since I'm stuck on a plane, I'll explain my crazy idea. I think I am going to require javascript for logged in users for the new version of the forums. The logic behind the madness is that it allows for a lot of optimizations. If a strongly parented relationship were to be implemented, structure would be very slightly different, it would go
thread -> page -> post. I've been toying with the idea of using etags with the forum. I would update the page's etag or last-modified when a post is added or edited. My dream would be to throw varnish or a CDN in front the forums and programmatically expire things from the cache.
If you put the forums in GAE you'll have a hell of a time getting the data out if you ever decide to move elsewhere. They limit data dumps in both size and format, do they not?
Posts
It is a harsh and uncaring deity.
Thanks for the report MKR. I looked at the parser code for vB, got scared, and then ran away. It might be trivial to fix, but my PHP / vB-fu is weaker than it was.
It's nothing more than a proof of concept at this point, but, yes. I have it written to run on our own gear, but I've also toyed with the idea of running it on Google App Engine. We would be at the mercy of Google's infrastructure, but it would cut down the operations overhead considerably
I've also looked at Microsoft's AppFabric/Azure cloud, but it has a higher cost for a lot of features I'm not sure we need on the forums. Ironically, the one thing that Microsoft does better than GAE is full text searching. Go figure.
I'm drifting off topic. If there are enough web devs interested in a thread, I would happily move this discussion to HA or the Tech forum.
Can you write DB wrappers so you can switch to another solution if App Engine proves problematic? I've never done anything more complicated than a half-functioning little CMS on it, so I don't know how hard that is at this kind of scale.
edit: It could go in the programming thread over in the tavern
I could use django-nonrel or something similar, but I'm not sure I want the full overhead of Django. I think to really tune the application for performance would require using a lot of GAE specific APIs / frameworks. I think that just breaking it into MVC will abstract things enough that it could be re-used later.
The main question I have is concurrency of inserts. I need to learn explore entity groups a bit more as it relates to datastore contention.
Right now, I debate between having one entity group per thread vs a "flat" approach.
A thread entity group would allow transactional updating of a thread and a post at the same time. This breaks down under two scenarios:
1) Really popular threads that receive more than 3-5 writes / second.
Solution: None. However, any errors would be contained to the thread.
2) Merging a thread into another / splitting a thread into two threads
Solution: None. A workaround would be to create new entities on the new thread and delete the old thread. In cases where over 500 posts would change threads, the process might be slow.
Since I'm stuck on a plane, I'll explain my crazy idea. I think I am going to require javascript for logged in users for the new version of the forums. The logic behind the madness is that it allows for a lot of optimizations. If a strongly parented relationship were to be implemented, structure would be very slightly different, it would go
thread -> page -> post. I've been toying with the idea of using etags with the forum. I would update the page's etag or last-modified when a post is added or edited. My dream would be to throw varnish or a CDN in front the forums and programmatically expire things from the cache.
we also talk about other random shit and clown upon each other
http://code.google.com/appengine/docs/python/tools/uploadingdata.html
It was only after this announcement that I started looking at app engine. Most of the other restrictions don't really bug me too much.
Things I'm still miffed about
I'll make you guys a deal, when I start thinking about this seriously, I'll make a thread in the tavern.