The problem is then you have to CHMOD to install plugins.

I still say the new table/query modification is the best for datastore, and hooks can take care or everything else.

So what if you have to CHMOD 1 file once?
You don't have to CHMOD the current datastore_cache every time you rebuild the vBOptions if you use the flatfile method, do you?
And even IF you would have to, it's still more efficient than adding queries or doing advanced parsing.

That's what I've done in the past on my site. It does work. But would defeat the purpose of the concept of plugins.

Nice to see there is some life in this topic again.

Let me just try to get the original problem clear again:
- You can do a lot without code changes with 3.5, there is however 1 thing you can not: If your hack adds a new entry to the datastore, you will have to edit each file to add your datastore item to the list of items to be fetched. You can not use hooks, because they are only loaded after the datastore is read.
- If we can easily without extra effort also add a simple way to do the same for template caching, then do so. It would reduce the number of plugins needed for your hack.

The original idea was to come with a solution that Jelsoft even might consider implementing, but since we are already on RC2, i doubt that will happen. Second best would be a standarized way of handling this as a community, so that whatever hack you use, file edits would only have to be made once.

How does it defeat the purpose of the concept of plugins?
If the hack is extensive enough to require datastore plugging into, it will also require file upload, so CHMODding a file wouldn't be hassle.
I don't really know, so DO you have to re-CHMOD the datastore_cache.php each time you update vBOptions?
If you don't, I don't see any reason why this should be any different.

If I had known this would concern me I would have replied earlier, XD
For my RPG I require a cache, but I just created my own table (rpg_cache, datastore table duplicate) and query this whenever I call $RPG->init(). I never really wanted to plug into the datastore table, because I wanted my variables to be $RPG->item not $vbulletin->item without too much hassle :p
Im not saying this to say "that's the solution", fyi.

The easiest solution would just be to hassle Jelsoft into adding a hook or two to enable us to do what we are trying to do.
If we have to come up with an uniform way of doing this, however, I believe my suggestion's downsides are far smaller than the disadvantages of adding an extra query to pages who won't even need this new field, and parsing the XML file on the fly (Imagine what would happen if the user has 15 hacks that require datastore modification, *shudders*).

This is why i opened the discussion, to find the best together. Your way of adding your own table for the rpg hack works, but will add another query also. If many hacks do this, this will mean many queries. And using custom datastore items in your own new script is not a problem. It is using them in plugins into jelsoft scripts that require code edits.

@Revan
Not every Hack that does require a DS item necessarily has to come with it's own Files.
Furthermore, it's impossible to intruduce Hooks to handle the Datastore Problem, as Plugins itself are being loaded from the Datastore.
My idea does not introduce a new Query, it just changes an existing one to have a JOIN and 1 more Condition.
As the Tables that would be used are pretty small, this should hardly cause any Overhead.

The idea of keeping a var_dump()ed array in a File is also nice, as it does not cause parsing or Query Overhead.
vBulletin itself does so, if you use the Class for a File-Based Datastore, so I think the CHMOD issue isn't a big one, as this would have to be done only once.
Hmm, Safe Mode and open_basedir restrictions could cause Problems here though.

How can I make a custom class recognise custom DS items then?
Oh XD
How so? After all, this file could be stored in the same way as the current ds cache file, which obviously work with Safe Mode and open_basedir...

Easy require the special templates.

Eh? Gonna need abit more detail than that, girl :p