Not really, bandwidth is not really an issue, since it is just a server process, and the datastore table will never have hundreds of records.

Edit: Memory used to keep the datastore in memory for later processing by scripts is more an issue then the memory used while retrieving everything.

I will try to make some alternatives tomorrow.

What I meat was a serialized array with the Requirements for each Product.
This item should always be queried then, the Load Routine should extract the currently needed Data (identified by scriptid/area) and merge it with the existing $globaltemplates, $actiontemplates, $phrasegroups and continue execution - just like it does with the XML Files idea.

I will have a sleep over this all, not sure yet that what you are suggesting could be done with less performance issues then the solution i posted above, but maybe we should write out all possible solutions and find some big boards who want to be testing it and marking execution times. On my localost, the above solution (including the query) added 0.01 second to the page load.

PS I made a reply at your thread on vb.com, asking others to join us here in the discussion.

I am not sure either :)
But in Theory a Query (if it's not heavy) should be faster then File Operations and Parsing.

I say it should load all the entries from the XML files regaurdless of whether the product is enabled or not to save the query.

I say Kirby's original idea at vB.com sounds good with a few tweaks for datastore stuff.

I will also have a go at implementing that idea tomorrow, unless someone else volunteers. In the end i hope that we come together with the best solution and try to persuade Jelosoft in integrating it, or we could use it here for all coders who want to use it.

Great idea, here are some comments

1. We really should find something to eliminate the need for an extra query and an xml parse for each page view. Large sites cannot afford this. Of course smaller sites can use this, but hack authors would still require filed edits, so their hacks don't slow down large sites.

2. Since there are file edits anyway, why not edit global.php instead. I think some re-arrangement can help, such as moving init_language to below a hook (can't see any side effects, but I could be wrong). This, I assume will solve the phrasegroup issue?

3. What's left are templates. But since we can already modify global templates with a plugin, and if it uses an if statement to check for the script being used before merging the hack's template, then we're done (except for special templates)

But, let's hope vB Dev's surprise us before gold, and we don't have to mock things up :) I noticed Scott's reply to Kirbey's thread, so I am optimistic.

Thanks for the input tamarian, will have a good sleep over this and try to find some alternatives tomorrow.

Didn't notice the reply at vb.com yet, but will go have a look.

To all other coders........input please.

It sounds like a great addition, but I would like to see what the Dev's take on this :)

Satan

I thought if you had another table all that would be required is to modify the datastore query that is already present to join another table with more conditions for extra things to pull

ie

[sql]
SELECT *
FROM datastore
JOIN NEW TABLE
WHERE title IN(blah) OR
NEW TABLE CONDITIONS (IF title=title and newtable.active)[/sql]