(2011-01-12, 04:01 PM)pavemen Wrote: [ -> ]It will also allow plugin authors to update/expand their included language files without overwriting existing customizations from users that would normally happen with a simple upload.
I agree that updating language files, without hurting customizations, is a problem with MyBB. But I don't think it can be solved by generating language files dynamically at runtime, with or without PluginLibrary.
I keep my own customizations in a separate language file which simply overwrites language variables of the original language files. So I can just overwrite/update those original files without having to worry about my own customizations. (Isn't the Custom Language File Plugin one of yours, anyway?). This is the only way that works for both stock MyBB, and plugin language files.
In general, language files should be shipped statically, and not generated by the plugin. Generating them would mean keeping the language strings around twice (in the plugin and in the language file). In practice, this would make plugins larger and give no advantage whatsoever.
So that leaves the possibility of making a function in PluginLibrary, that creates language files based on an array; however this function should only ever be used by plugins that for some reason, can't ship a static language file. So the documentation would have to make very clear that this is not for static language files.
I'm not sure if this is a good idea or not. Developers could get the wrong idea just by seeing the function...
The code to generate a language file, is trivial by itself, basically a one liner, for example
$langfile = "<?php\n\$l = array_merge(\$l, ".var_export($yourlangdata, true).");\n?>";
so it's easy to do yourself if you really need it.
I added an issue for this so I'll keep it in mind:
https://github.com/frostschutz/PluginLib...es/issue/1
Its an option, that is all.
My one case is probably the only case such functionality exists for MyBB right now since as you said, most of the time the language files are static. Since I am allowing admins to create custom tables and basing output on the table structure, I need to be able to create supporting language files when a structure is created (and allow admin to change corresponding verbiage at any time).
Yes, the custom language file is mine, but it does not address someone using a plugin that includes langauge support that the admin has modified, that is overwritten by the plugin's language file during an update.
Its not a huge issue, but it would be nice if we could tell the admin to not upload the new language file and some upgrade code in the plugin will make the needed changes.
I have my own function I use but I thought it was worth a shot putting out there
There's a hitch.
Found out today that MyBB loads all caches unconditionally for every request (if it's database cache, which is what most people use as that's the default). I thought these were loaded on demand.
So I might have to remove the delete_cache() function (since it's not a good idea to add 100 plugin caches, ram usage will explode), and instead implement a full blown cache mechanism (which is then on demand, i.e. loads cache only for the page that needs it). Depends on whether the MyBB devs would be willing to change this behaviour or not...
(2011-01-13, 10:24 AM)frostschutz Wrote: [ -> ]There's a hitch.
Found out today that MyBB loads all caches unconditionally for every request (if it's database cache, which is what most people use as that's the default). I thought these were loaded on demand.
So I might have to remove the delete_cache() function (since it's not a good idea to add 100 plugin caches, ram usage will explode), and instead implement a full blown cache mechanism (which is then on demand, i.e. loads cache only for the page that needs it). Depends on whether the MyBB devs would be willing to change this behaviour or not...
Could you please elaborate a bit more?
http://dev.mybb.com/issues/1406#change-6741
Anything you put into a MyBB cache will be loaded into RAM for every request, regardless whether you actually call cache->read("yourcache") or not. So I'm not sure anymore whether PluginLibrary should provide a cache related function (thereby encouraging to use cache) when overall, it's possible that it adds more load, instead of reducing load.
Or maybe I'm worring about nothing - they're driving me crazy with their optimizations.
Thanks!
Do you mean this here:
if(is_object($this->handler))
{
if(method_exists($this->handler, "connect"))
{
if(!$this->handler->connect())
{
$this->handler = null;
}
}
}
else
{
// Database cache
$query = $db->simple_select("datacache", "title,cache");
while($data = $db->fetch_array($query))
{
$this->cache[$data['title']] = unserialize($data['cache']);
}
}
?
Yes, the database cache... looks like I'll have to roll my own. That really sucks.
Okay, looking at the cache class more closely, I think I can piggy back on it. It'll be ugly though, and changes to the cache class could cause it to break then, but at this point I think I don't care.
So in addition to delete cache, PluginLibrary will get functions to store, and read cache, as well.
yeah, the cache is loaded all the time and $cache->read is just a simple way to get an unencoded array
however, what is the trade off with an on demand system? assuming 99% of MyBB users use the DB method, its disk i/o and more queries versus ram usage. if you load the entire cache all at once, its a single query with each page.
an on-demand system would pull the default cache items that are needed for each page, and then every call to the cache from then on would be another DB query.
the $cache->read would need to see check if the item is already loaded into the cache and then if it is not, run another query to grab the new stuff.
if you are worried about ram usage, suggest that MyBB minimize and clean up the $mybb variable to remove things it does not need that much and also clear up redundant variables.
example
$mybb->config is a copy of $config but $config is never unset after being pushed into $mybb.
Say you're caching 1MB of data. That means that for every single request (regardless of which page), that 1MB of data will have to be served by the DB, parsed by PHP, and kept around in memory, just in case your plugin needs it.
If your plugin does something fancy to the index page (such as an overview of latest threads, users, advanced statistics, etc, stuff that's expensive to calculate and thus an ideal candidate for caching), that means this additional data is loaded in vain for every other page (forumdisplay, showthread, profiles, rss feeds, user cp, etc. etc.).
If you have 10 plugins like that you're wasting 10MB of memory for every single request. At some point, it will become noticable. So an on demand cache would be preferable for things that just are not needed all the time. Yes, it will need an extra query / file load operation then. But if it takes one query to load a cache, and a hundred queries to rebuild the contents of the cache from scratch, the one query is still preferable.
but who caches that much data? my entire cache table is 350kb (max has been 1.2mb) . how much information are you expecting plugin authors to start caching?
perhaps the mybb cache can cache only the default items for the system and then plugin authors can add to the cache as needed, but then if its needed on demand, why not just query the DB to get what you need into a variable accessible to the entire plugin and not bother with the cache?