Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="Janx" data-source="post: 5907560" data-attributes="member: 8835">in many ways, Morru's idea of users picking from a list of generators was more like a Canned Report model, and my idea of them using a console to submit text was more like a canned report.technically, this stuff ran great on my 386 back in the day with very complex table trees.  Running off of flat files would probably work very fast.  I'm a little concerned if we store each Asset in a DB Row, as each tag would basically require a trip to the DB to fetch the next Asset and parse it.The actual parsing should be fast.  The fetching of the next Asset could be slow if we don't consider ways to do it faster.On Celebrim's point about being able to make the table return a specific result, I agree.  That's something I alluded to in an early post as part of the scripting language syntax.On C's point about weighted values:good idea, though I might adapt the idea to being another way to define table entries.  Normal humans will look at tables in the DMG and enter them as begin/end ranges for each row.  Some people will realize they only need to define the begin number, as the next entry caps off the previous's range.  Other folks like C will just want to set a weighted value.  The engine isn't really stressed to handle any of that.To recap on performance:the biggest performance barriers I see are getting from the current text to process the next tag in that text.  This nesting or recursing could be slowed down by whatever steps we have to take to open up the asset.It's also possible that are actual parsing technology for a string could be slow.  I discount that as much by the fact that this technology ran just fine on 386s, including nested tables.[MENTION=27229]MoR[/MENTION]uss:is it possible* with vBulletin that all of the assets could be stored as flatfile on the webserver (or wherever attachments are stored, in a seperate directory) rather than being stored directly in the vbUlletin database?this would simplify the design, provide a model that works online or offline.  We'd still tie the screens into vBulletin, but we'd store the actual meat in flat files (perhaps one file per asset).*possible as in "does this fit in with what you're allowed to do with Enworld's host and design preferences".  I know we can make PHP do whatever we want.</blockquote>

Verification