new super key suggestion

[Wormopolis]

A "Forum Key" that allows you to store data globally (accessible from any pages, regardless of content).  this would allow a dynamic storage device to a forum that could provide consistency between pages of data.  counts as a "super key", and adheres to same standards as the other keys (4K size, no set on pageload).

[CheatAreZee]

Hey Wormopolis,

I'll tag a couple of developers to provide input on whether or not this could be added

Keith Rozett, Tim Camara

[Tim Camara]

I think Pat would have to sign off on this idea. I'll have him take a look at it when he gets back in.

[Keith Rozett]

If I understand you correctly, couldn't you just use a regular super key, and set the read/write permissions to everyone? Then you can store/retrieve data under user id 1, since every user can access it.

EDIT: Tim just explained to me why it won't work. D'oh!

[David Clark]

Jul 12, 2013 14:24:52 GMT -8 Keith Rozett said:

If I understand you correctly, couldn't you just use a regular super key, and set the read/write permissions to everyone? Then you can store/retrieve data under user id 1, since every user can access it.

EDIT: Tim just explained to me why it won't work. D'oh!

Out of curiosity, why?

[Tim Camara]

That will only work on pages where the admin user is being loaded. So if you're logged in as the admin user, everything's peachy. If you're any other user, and on a page where the admin account isn't (calendar, edit profile, any thread they haven't posted in, etc.), their data won't be loaded, plugin key data along with it.

[David Clark]

Oh. In that case, yeah - something like what Wormo is describing could be very useful.

[Wormopolis]

considering it would just be one key for the forum, perhaps it could be larger in size then a regular key - i.e. larger then 4K. as a suggestion, maybe the max size of a post itself?

[Tim Camara]

Good news, everyone! Pat just greenlit this idea. Currently, the way it's planned to work is as follows:

- Each forum super key (final name TBD) will require one super key spot on your forum.
- They will have a larger space available than a normal key; Right now it's looking like either 16k or 32k pending further discussion with Martyn.
- They will be available on every page, regardless of what other data is loaded.
- They will behave otherwise exactly like a normal super key, and be subject to all the same restrictions on usage.

I'm currently working on some long-awaited updates to some Library stuff, so hopefully I can talk Keith or Vinh into implementing this quickly.

[Wormopolis]

SWEET!

name suggestion: wormo key.


just a thought

[Peter]

With this forum super key, will it be possible to append data rather than overwrite it?

So you could add an extra parameter where we can pass in a boolean. By default it will overwrite, but with the parameter set, it appends the data instead.

Considering the size of the key (and only being 1), and I doubt any plugin will need all that space (if you do, then ignore my proposed solution to share it).

I think we should discuss about sharing this key right from the start so we can all use it to write too. It's simple enough to do, have a root object and each of us gets our own key in the object. If no root object exists, create one. This is handled by us, not by ProBoards. There is no reason why you couldn't just be greedy and overwrite the key data for yourself, but considering the type of key this will be, I think it would be a good idea.

var data_str = proboards.plugin.key("wormo_key").get();
var data = JSON.parse(data_str) || {}; // Should check if valid json first though

if(!data["wormo"]){
data["wormo"] = {};
}

// Data example that gets stored in the key
// {"peter":{"hello":"world"},"womo":{"hello":"world"}}
Only problem we have, is that if the key is in use, ProBoards will not allow the plugin to be installed. 

Anyway around this Tim Camara, apart from having an empty plugin just to hold the key for everyone?

[Pebble]

Great news for me as I have a personal project that requires this!

Also good news in general!
If my understanding is correct this will be a proboards cookie, but bigger? (roughly speaking)
If the PB's cookie has a set name then sharing shouldn't be a problem as far as I can see (as the key data would be extracted, added to, and then re-written, as long as there is room in there, and with 32K that should be more than enough.)

[Wormopolis]

I was just kidding calling it "wormokey"

implementing a JSON system has my vote as well. if it is put into the developer guide that its required to access it that way might just keep accidents from happening in the first place. there needs to be a disclaimer that it could happen though.

[Tim Camara]

Okay, some further updates on this front:

I hate to rain on anyone's parade, but the talk of sharing a single key to store non-related data is causing Pat to look more critically at allowing this type of key.  There's no official rule about this yet, but it seems like the line is going to come down roughly to be that you can share a key if the data stored within is all related, but storing non-related data in the same key is bad.  Purely from a business perspective, providing a way to circumvent the super key restrictions doesn't make sense, so if we provide this type of key, it's likely to come with a restriction to prevent exactly that.

On the more positive side, we've decided to implement the following additions to key setting functionality:

• Append
• Increment
• Decrement
• Push
• Pop

Increment and Decrement will obviously only work correctly on integers, and Push and Pop will only work correctly on arrays.  

[Chris]

Jul 24, 2013 8:38:05 GMT -8 Tim Camara said:

On the more positive side, we've decided to implement the following additions to key setting functionality:

• Append
• Increment
• Decrement
• Push
• Pop

Increment and Decrement will obviously only work correctly on integers, and Push and Pop will only work correctly on arrays.  

Thanks Tim,

am I reading too much into this or are the addition of these data manipulation methods also a way to address key data (over)writing conflicts in near-simultaneous key operations? I also assume these methods will be documented in this thread once pushed?