Key Size Limit

[Wormopolis]

Dec 30, 2012 15:35:05 GMT -8 blueshead said:

Dec 30, 2012 15:25:04 GMT -8 Chris said:

Most plugins don't need keys though.

Yes.. But will they know that by using a key they will impact proboards customers?  Will you tell them this?

Its not really Chris's place to demand other developers follow certain guidelines.  He shouldnt have to take on responsibility like that.  If he saw a better way to do something, he could suggest it to the author, but really its entirely up to the author how they write the code. 

Any code that has a necessity to store information where more then one user needs access to it, will have to use plugin keys. you always have the option of just not installing the plugin.

[Todge]

More than one plug-in can share a key too, so long as the coder keeps tabs on how much data is being stored, so you can have more than 10 plug-ins using less than 10 keys.

[Bennett 🚀]

Dec 30, 2012 14:23:03 GMT -8 Chris said:

Right, and so plugin developers need to be smart.

1) Use the yootil library which lets you store settings in localStorage. This is in compliance with the EU cookie law AND removes the need for a key.
2) Reuse keys across plugins by the same developer. That is, if data needs to be stored across multiple plugins, I will make my codes share a key.

But the size (4kb) has nothing to do with needing more keys. So that's why I said it's best to just ignore it.

localStorage is just that, though -- local. If you go on a different computer, things won't be saved unless you somehow have the library save it on PB and then re-store it in localStorage.

[Chris]

Jan 21, 2013 19:14:14 GMT -8 Bennett 🚀 said:

Dec 30, 2012 14:23:03 GMT -8 Chris said:

Right, and so plugin developers need to be smart.

1) Use the yootil library which lets you store settings in localStorage. This is in compliance with the EU cookie law AND removes the need for a key.
2) Reuse keys across plugins by the same developer. That is, if data needs to be stored across multiple plugins, I will make my codes share a key.

But the size (4kb) has nothing to do with needing more keys. So that's why I said it's best to just ignore it.

localStorage is just that, though -- local. If you go on a different computer, things won't be saved unless you somehow have the library save it on PB and then re-store it in localStorage.

Most of the time you don't need them to be reliably stored and aren't important.

[Bennett 🚀]

Jan 21, 2013 21:41:41 GMT -8 Chris said:

Jan 21, 2013 19:14:14 GMT -8 Bennett 🚀 said:

localStorage is just that, though -- local. If you go on a different computer, things won't be saved unless you somehow have the library save it on PB and then re-store it in localStorage.

Most of the time you don't need them to be reliably stored and aren't important.

Ah, okay. I had the example of like an awards system stuck in my brain.

[Chris]

Jan 21, 2013 23:19:07 GMT -8 Bennett 🚀 said:

Jan 21, 2013 21:41:41 GMT -8 Chris said:

Most of the time you don't need them to be reliably stored and aren't important.

Ah, okay. I had the example of like an awards system stuck in my brain.

Yeah, that should use a key.  Agreed.

[Todge]

Dec 30, 2012 14:23:03 GMT -8 Chris said:

Right, and so plugin developers need to be smart.

1) Use the yootil library which lets you store settings in localStorage. This is in compliance with the EU cookie law AND removes the need for a key.

The Yootil Library does not let you use LocalStorage, that is basic JavaScript and is available to any coder, whether they use the Yootil Library or not.

Don't get me wrong, Yootil is a great plugin, but is not needed for Local or SessionStorage.

[Thesealion]

Dec 30, 2012 14:23:03 GMT -8 Chris said:

Right, and so plugin developers need to be smart.

1) Use the yootil library which lets you store settings in localStorage. This is in compliance with the EU cookie law AND removes the need for a key.
2) Reuse keys across plugins by the same developer. That is, if data needs to be stored across multiple plugins, I will make my codes share a key.

But the size (4kb) has nothing to do with needing more keys. So that's why I said it's best to just ignore it.

Do you think you could do a demo of #2 Chris? I am a bit shady on how you would keep from overlapping data and stuff

Jan 22, 2013 10:11:42 GMT -8 Todge said:

Dec 30, 2012 14:23:03 GMT -8 Chris said:

Right, and so plugin developers need to be smart.

1) Use the yootil library which lets you store settings in localStorage. This is in compliance with the EU cookie law AND removes the need for a key.

The Yootil Library does not let you use LocalStorage, that is basic JavaScript and is available to any coder, whether they use the Yootil Library or not.

Don't get me wrong, Yootil is a great plugin, but is not needed for Local or SessionStorage.

If I remember correctly Yootil does make it much simpler to use Local Storage

[Todge]

What's simpler than

localStorage.object = 'data';

and

var xxx = localStorage.object;

?

[Thesealion]

True...

[Peter]

Jan 23, 2013 10:03:53 GMT -8 Todge said:

What's simpler than

localStorage.object = 'data';

and

var xxx = localStorage.object;

?

Yootil Storage is more than that.  It supports persistent and session storage, along with providing cross browser solutions.  So, considering IE 7 is officially supported by ProBoards, HTML 5 Storage (in your case) will fail.  So then it would be a good case to use Yootil, as that handles it for you.

In your example, you are making it very basic, and if that's all you were going to use for your Plugin, then yeah, that's totally fine.  But you are making Yootil sound like it's a waste to use it just for storage without looking at what it does first.

github.com/pixelDepth/Yootil/blob/master/src/storage.js
github.com/pixelDepth/Yootil/blob/master/src/storage.persistent.js
github.com/pixelDepth/Yootil/blob/master/src/storage.session.js

[Chris]

Don't fall into the trap of thinking because it is called the "EU Cookie Law" that means switching to localStorage is a way around it since it covers ALL forms of client storage (cookie,flash LSO,html5, etc.) and concentrates more on the necessity and sensitivity of the information rather than the method of storage.

Cookies Regulations and the New EU Cookie Law

[Todge]

Jan 25, 2013 5:35:49 GMT -8 Peter said:

Jan 23, 2013 10:03:53 GMT -8 Todge said:

What's simpler than

localStorage.object = 'data';

and

var xxx = localStorage.object;

?

Yootil Storage is more than that.  It supports persistent and session storage, along with providing cross browser solutions.  So, considering IE 7 is officially supported by ProBoards, HTML 5 Storage (in your case) will fail.  So then it would be a good case to use Yootil, as that handles it for you.

In your example, you are making it very basic, and if that's all you were going to use for your Plugin, then yeah, that's totally fine.  But you are making Yootil sound like it's a waste to use it just for storage without looking at what it does first.

github.com/pixelDepth/Yootil/blob/master/src/storage.js
github.com/pixelDepth/Yootil/blob/master/src/storage.persistent.js
github.com/pixelDepth/Yootil/blob/master/src/storage.session.js

The difference between localStorage and sessionStorage is just that, you use local instead of session.

I'm not suggesting that using Yootil is a waste of time, I was originally pointing to the fact that you do not NEED it to use HTML5 storage, it got morphed into that with my reply to Thesealion, but considering IE7 usage is now below 4% it will soon not be necassary to even check for that.