Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[For 1.8] Drafts AutoSave – Save posts and threads as drafts automatically
#11
(2014-05-14, 01:45 PM)Shade Wrote: Yes, it does. Nothing particularly tough for the server - but that's the point. I need to ensure the best perfomances while keeping a low backend impact. Both of the two ways to achieve this - client-side and server-side - have their advantages and disadvantages and a combination of the two might be the final solution. I still need to think it though.

disadvantages you said is because of post of @VirusZero?
I still prefer zero resource usage...
Personally for me jstorage is best solution...
Reply
#12
(2014-05-14, 01:51 PM)frostschutz Wrote: One thing to be aware of when using PluginLibrary's cache. It's not a filecache. It only uses file cache by default to avoid MyBB's default DB cache. If you have configured any other caching method, like memcache, it uses that instead. I'm sorry if that isn't clear from the documentation.

In the end, it's a cache function, not a save function. It's intended for data that, if missing, can be rebuilt easily, like a HTML representation of DB data that you do not want to re-query with every request (but can re-query when it's gone). The documentation does state that the cache is allowed to vanish at any time. It's different from MyBB's cache which is always backed by DB (and autoloaded with every request if you actually use the default DB cache).

As such for your drafts, if you want them saved, my recommendation is that you use DB (your own table if you like) as saving things is its purpose.

I thought it was a filecache. Whatever, I chose it just because it can vanish at any time on purpose. Auto saved drafts, if saved into the db, might cause really high loads on the server and that's what I'm trying to avoid.
[Image: fSGNVQj.png]
Reply
#13
i try to say 1 query on start thread hook and 1 on send thread, upgrade to users table and there are new field into sb called shade_das with true and false value only adding to true on start thread and finally to false if you send your thread.

And check in login for this value to verify if true you receive new message to advice users who have drafted messages xD. This for more secure and no more querys than mod needs xD.

I try to say this hook use on login only xD.

Other two on start thread and on send thread to db, that was great for me xD. because i forgot sometimes to send some threads or page was changed automatically for some kind of reason.

If not on login maybe can use hook like pms advice if you have some draft you have a new message and theres if you have more than one, you receive a notification like mps that's all.

Or only when you start your sessioncan see if you have drafted threads and you can verify if you want to delete or modify or finish this and send xD.
The only infinite thing is the universe and human stupidity, but the universe is not for sure

Plugins 1.6.x

Plugins 1.8.x

Reply
#14
What about a hybrid approach?

So maybe the system will auto save (either via cookie or localStorage or the filecache or etc...) every <configurable seconds> amount but then at <configurable minutes> amount the system will then save that copy to the database in the drafts?

Also, to prevent some issues:
- have check to ensure someone doesn't set cache/cookie-save to like 120 seconds and then database-save to like 1 minute (which would increase the number of queries made and defeat the purpose of the cookie/cache save).
- have a lowest allowable limit on how often the system can save (for both cache/cookie and database modes). So this way someone can't set the system to auto-save every 10 seconds to database.

Then when you go to load, it'll check for the quicker/new version first and if it doesn't find one then it'll default to whatever is saved in the drafts section?

Also maybe have a check so that if the system detects no changes to the draft that it won't waste any queries and update the database. (So like if someone leaves a post sitting for like 5 minutes it saves the draft to the database, but then on next check it sees the draft hasn't changed from the cached/cookie version so it doesn't update the database copy. Then if it detects the change to the cookie/cache version again on another check it'll update when the timer trips then.)

Perhaps also allow the option to disable saving to the database (in case the server strain gets too high but the function to auto save to cache/cookie is still useful) so users can just have the auto-save function like how vanilla's works. (Which some may want this option anyway.)

This might be a touch more complicated... but it'd possibly provide the benefits of both without hopefully impacting server resources too much.
My MyBB 2.0 suggestions - Mass edit group permissions - Post based Anti-spam
Reply
#15
(2014-05-14, 08:30 PM)VirusZero Wrote: What about a hybrid approach?

So maybe the system will auto save (either via cookie or localStorage or the filecache or etc...) every <configurable seconds> amount but then at <configurable minutes> amount the system will then save that copy to the database in the drafts?

Also, to prevent some issues:
- have check to ensure someone doesn't set cache/cookie-save to like 120 seconds and then database-save to like 1 minute (which would increase the number of queries made and defeat the purpose of the cookie/cache save).
- have a lowest allowable limit on how often the system can save (for both cache/cookie and database modes). So this way someone can't set the system to auto-save every 10 seconds to database.

Then when you go to load, it'll check for the quicker/new version first and if it doesn't find one then it'll default to whatever is saved in the drafts section?

Also maybe have a check so that if the system detects no changes to the draft that it won't waste any queries and update the database. (So like if someone leaves a post sitting for like 5 minutes it saves the draft to the database, but then on next check it sees the draft hasn't changed from the cached/cookie version so it doesn't update the database copy. Then if it detects the change to the cookie/cache version again on another check it'll update when the timer trips then.)

Perhaps also allow the option to disable saving to the database (in case the server strain gets too high but the function to auto save to cache/cookie is still useful) so users can just have the auto-save function like how vanilla's works. (Which some may want this option anyway.)

This might be a touch more complicated... but it'd possibly provide the benefits of both without hopefully impacting server resources too much.

This is what I needed. I will do my best to develop it like this.

Btw, checks for changed/empty messages have already been implemented (also, when an user goes idle or changes tab/page on his browser, the system will break the function cycle call and disable any saving options).
[Image: fSGNVQj.png]
Reply
#16
My previous suggestions on this topic was to use JS to load the message contents into a cookie on specified intervals.

4kb of base64 encoded text is a lot of storage. When the draft or submit button are used, clear that cookie.
Lost interest, sold my sites, will browse here once in a while. It's been fun.
Reply
#17
(2014-05-14, 08:35 PM)pavemen Wrote: My previous suggestions on this topic was to use JS to load the message contents into a cookie on specified intervals.

4kb of base64 encoded text is a lot of storage. When the draft or submit button are used, clear that cookie.

Wouldn't it be easier to use HTML5 localstorage? Just asking.
[Image: fSGNVQj.png]
Reply
#18
Not all browsers support it. Think of those of us stuck with corporate computers or libraries with old browsers, etc. If you can work it out to test for localstorage and use that, if not fall back to cookies, then that would work.

But then think about mobile browsers.
Lost interest, sold my sites, will browse here once in a while. It's been fun.
Reply
#19
I completely agree with pavemen. Cookies sound like the perfect solution.
[retired]
Reply
#20
Agreed with pavemen too. Lob it in a cookie, then possibly think about persisting to db on window close (if not posted).
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)