The Throwback (retro) template. With large folder and mobile support.

[danny]

Available at Post#1 is the complete set of Throwback 14. 

The prior cleanup fit resulted in a tidy open-source version of throwback.  Throwback14 was previously stuck in development; however, when I tried the already-made #14 modules aboard the tidy open source version... all of the sudden, everything worked straightaway. 

So, rising from the ashes is Throwback14, the Phoenix. http://rejetto.com/forum/index.php?topic=12055.msg1062733#msg1062733

[danny]

Good! thanks for sharing...

Also shared, many more files at Post#1, both historic and the latest available.
See also the WatchCat script, so you can go on vacation yet the server stays up. 

[LeoNeeson]

Also shared, many more files at Post#1, both historic and the latest available.

Cool! I'm still testing them, but they look good (Throwback14 loads blazing fast). My favorite is Throwback14MP.tpl. Overall speaking, you did a great job (it looks like a finished/completed project), congratulations!

» Details: I see you removed my XHR login on Throwback14 (in the 'unauthorized' section), but it's still there for those who may need it, on Throwback10v3.tpl (inside the 'historic.zip' file). I personally don't need the XHR login. I've did it (see my post HERE), for those browsers who removed legacy HTTP Auth. Anyway, my XHR login implementation, was not reliable, since when the connection is time-out or closed, the login is forgotten (and it asks to login again and again). To be reliable, it should store the credentials on a cookie, and automatically issue the XHR login (on background), if the credentials are found in the cookies (this should happen when the user 'clicks' on a password protected resource, but BEFORE any connection is sent to the server). This way, it will work on both (new and old browsers), and it will never show up that login popup again, obviously, unless some user tries to DIRECTLY cold-access a password protected file (I mean, without browsing for the file, since on that case we can't avoid having the login popup showing up from the browser). This is the general idea on how to complete the XHR login, but I didn't had the time to complete it. If anyone wants to continue it, it's welcome to contribute on THIS thread (the only rule to submit any code contribution, is please NOT using jQuery, neither ES6 or Promises, to keep compatibility with old browsers too).

Cheers,
Leo.-

[danny]

Cool! I'm still testing them, but they look good (Throwback14 loads blazing fast). My favorite is Throwback14MP.tpl. Overall speaking, you did a great job (it looks like a finished/completed project), congratulations!

Thanks ever so much!  I wouldn't have done so well had it not been for the stout/clear and helpful briefing that you gave me (also kudos to Rejetto for a do-in-scope briefing).  And, yes, it is intended as the series finale, at least for now.  Sharing all that I could, was good advice.

...removed my XHR login...

I did.  For the phones, I put a note to use a browser that is compatible.  It is a new development, since mobile browsers with basic-auth capacity have only recently become available, via firefox.

...My favorite is Throwback14MP.tpl...

MP was always the favorite.  This is why Throwback14dphoto behavior and default workload is very similar to MP.  Because of the new state-of-the-art color css unicode icons, today I tested large folder support again.  I got 234,691 files on a single page during the test (of a disk with exactly that many files). It went a minute faster.  And I did it from a cheap TracFone on metered mobile data.  So, the newest did have large folders support. Test was done with the photo version; and, this time, minus the bill.  Perhaps, the #14 photo version is now eligible as a favorite.

...14 loads blazing fast...

Throwback was always dual purpose.  #1, serviceably fast.  #2, a practical message  to the developers:  never less than this.

...finished...

Indeed, the classic/interactive interface is stuffed full.  Although it surely will arise again, the next step should have its own name and its own thread. 

[SilentPliz]

Danny,

I've sticked your topic.

[danny]

Throwback for new HFS2.4 added at the first post. It is the popular MP version, updated to the new login system. 

See also HFS2.4 release candidates and changes for HFS2.4 templates

[danny]

• version for HFS2.4 rc4, available at post#1
• version for rc3 works betas, rc1, rc2, rc3 available at post#1
• change password feature is updated
• large scripts are now cached for bandwidth savings. 
• code !%user% revised to not|%user% for the auto error handler
• The login page now reloads in case of bad password.

[NaitLee]

• large scripts are now cached for reduced overhead. 

I'm still wondering which way is recommended:
  [sym-audioplayer] for speed, or [audioplayer.js] for data reduce?

[danny]

I'm still wondering which way is recommended:
  [sym-audioplayer] for speed, or [audioplayer.js] for data reduce?

[sym-name] is for isolating HFS-macros so they don't run instantly.   It can't help speed of javascript.
However,
[name.js] works like an external file, and you can install a caching header for bandwidth & speed. 
So, [name.js] is recommended for large scripts. 
Notice that an additional html-transit request has cost, so this is not for small-size scripts. 
You can use [name.js] to send caching-headers for large-size javascripts.
Like this:
[name.js]
{.add header|Cache-Control: public, max-age=86400.}function...

Limits setting could stop loading; so, here's the workaround:  <script defer src="/~name.js" onerror="setTimeout(()=> this.src='/~name.js', 180)">

[danny]

This file is for testing Photo Thumbnails ondemand (click photo icon), with HFS2.4rc4
Enjoy!  And, let me know how you like it.

[rejetto]

if i were you, i would do something like
onerror="errHandler(this)"

and have a separate function like
function errHandler(el) {
   setTimeout(()=> el.src=el.src, 180)
}


this should allow you to
- avoid code duplication
- decide to implement a more sophisticated logic, but only once. For example a loop retrying N times, or an increasing time instead of a fixed one (180) to have less requests at the same time.

[danny]

For example a loop retrying N times, or an increasing time instead of a fixed one (180) to have less requests at the same time.

I wish that I knew how to do that, but I'm not a javascript expert.  Even a small edit usually takes me a full day to make it work; and, sometimes much longer. 

Indeed, your increasing time idea has merit, because 500ms is slightly overlong for wait and Also the minimum amount of time to relax/rest a busy server in-between retries.  If there was connections max, then 180 works or if busy, then 500+ works (less makes blanks).  It would be good if the 3rd retry was at a longer time. 

Alas, all I can do is change it to 509, which is a prime number, for less chance of concurrent retries.
Yes, 503 was nearest prime; but, Throwback has only 5.4ms overhead (not 27); so, next up prime is 509. 

Also, with HFS macro, I made the photo button, script and archive, all go missing (not sent) if conditions:  60 megabits + 1 download, or 30 megabits + 2 downloads, or 15 megabits + 4 downloads, etc (like the throwback for 2.3 except more elegant).  It is effective to prevent overload, but is there a better way to detect workload? 

re-uploaded at https://rejetto.com/forum/index.php?topic=12055.msg1066107#msg1066107

[rejetto]

I wish that I knew how to do that, but I'm not a javascript expert.  Even a small edit usually takes me a full day to make it work; and, sometimes much longer. 

the world is full of web developers. You should know someone to ask for help.

Alas, all I can do is change it to 509, which is a prime number, for less chance of concurrent retries.

i'm totally missing how the 'prime' attribute helps you with the chance of concurrent retries.
I guess it just doesn't.

Also, I made the photo button, script and archive, all go missing (not sent) if conditions:  60 megabits + 1 download, or 30 megabits + 2 downloads, or 15 megabits + 4 downloads, etc (like the throwback for 2.3 except more elegant).  It is effective to prevent overload, but is there a better way to detect workload? 

i tried your tpl with a folder with few photos and couldn't see any problem. I'm also failing to understand what's causing yout these limits, if are some limits that you set or something else. I really wish to know.

[danny]

. . . i tried your tpl with a folder with few photos and couldn't see any problem. I'm also failing to understand what's causing you these limits, if are some limits that you set or something else. I really wish to know.

There is some difference because I tested with 600 photos.  It worked fine.  The template has several ways to decrease/conserve workload.  So, it doesn't need the limits menu settings (they were not enabled).

A one-user test at localhost wouldn't show it; but, the 509ms gives HFS enough time to run the ui and serve other users, and/or lower cpu-load.

The all positive outcome, wouldn't answer all of your question. 
Because it is efficient and cautious, throwback is not usable as a stress-test.   So, I will make a different example and post it to the 2.4 templates thread.

[danny]

Throwback for HFS2.4 RC5 added at the first post.
It works for RC4, RC5, etc

See also HFS2.4 RC5

Hot tip:  Choose what folder you see after login
Menu (not in easy mode)
Other options
User accounts
group (can change password)
After login, redirect to
/

Edit: Re-uploaded with a better login for phone/mobile.   Thanks DJ!!!