rejetto forum

Software => HFS ~ HTTP File Server => Topic started by: rejetto on December 19, 2021, 10:08:30 AM

Title: a new beginning...
Post by: rejetto on December 19, 2021, 10:08:30 AM
Hi guys, and sorry if I've been quite a ghost. :)

For those of you who care, I'm trying to reboot the project.
You'll find it at https://github.com/rejetto/hfs
This is actually replacing a previous attempt that was at the same address.

I have no idea if I'll be actually able to bring it to the dignity it deserves, and that's a thought that has often stopped me from starting.
I decided to give it a shot, and we'll see.

The current state of the project is "very early stage" and it's probably not good enough for most of you.
It is probably good enough to replace it in my daily use: you get the VFS and basic accounts.

There's no "simple exe" distribution yet, so for most of you it may be hard to even start it as it is now.
I will take care of this kind of things later in the project.

Many of you already know that I don't like working on the old HFS (delphi) since long. Starting anew is the only way to enjoy it.
Cheers
Title: Re: a new beginning...
Post by: rejetto on December 21, 2021, 03:14:07 PM
if someone is so bold to start playing with it
https://github.com/rejetto/hfs/releases/tag/v0.2.0-alpha

I'm already using this on my NAS.
Title: Re: a new beginning...
Post by: mandoz on December 21, 2021, 05:07:50 PM
dear friend, i'm waiting for exe file :o :o :o
Title: Re: a new beginning...
Post by: dj on December 22, 2021, 09:13:58 AM
I did something wrong
"tsc" could not be found
Title: Re: a new beginning...
Post by: LeoNeeson on December 26, 2021, 11:04:35 PM
@Rejetto: It's nice to see you again, after a long time. For as long you enjoy what you do, having a new (future) HFS is always good news. I guess there is still a long road before we could have a single executable file, but for advanced users it looks very interesting. Congrats! :)
Title: Re: a new beginning...
Post by: rejetto on December 31, 2021, 09:46:29 AM
I did something wrong
"tsc" could not be found

I'm sorry i didn't answer before, i was relying on email notifications while they are apparently not working, maybe since i had to switch webhosting.
Consider you don't need to "build" because you get releases that are already built.
WHen you run it with "node ." you get EPERM on accounts.yaml, and that's a bit strange. Maybe you had it open with a software locking it. Double check the file status.
And also check new release
https://github.com/rejetto/hfs/releases/tag/v0.3.0-alpha

I'm very excited, this project is going very well.
I already got ZIP files without overhead on the server, just like we had with TARs.
At the moment it doesn't support resume of ZIPs, but that's ok for the moment. It took me a lot of work to get it working correctly like it is.
Title: Re: a new beginning...
Post by: rejetto on December 31, 2021, 10:41:53 AM
i just added an exe.zip for those who don't want to install node
https://nodejs.org/

The exe is actually packing both "node" and "hfs" in a single file, and that's why it's big.
Title: Re: a new beginning...
Post by: dj on December 31, 2021, 03:30:28 PM
v0.3 and
exe: This app cannot be run on the PC
Title: Re: a new beginning...
Post by: rejetto on December 31, 2021, 04:17:59 PM
i think i know what's going on here.
That crc32 module is a library using machine-dependent code for optimal performance, and i'm including only the version for my machine (crc32-win32-x64-msvc)
while yours is different (crc32-win32-ia32-msvc).
It tries to load the other version and doesn't find it.
It should run smoothly on an x64 machine instead.
I'll have to see how to solve this "distribution" problem.
Title: Re: a new beginning...
Post by: rejetto on December 31, 2021, 04:37:47 PM
this should solve your crc32 problem:
enter hfs folder and run:
npm install @node-rs/crc32-win32-ia32-msvc --force


Can you tell me what CPU are you running it on? Or is it a VM ?
Title: Re: a new beginning...
Post by: rejetto on December 31, 2021, 04:57:05 PM
in the meantime i renamed the exe zip into exe-x64 so to let people know that is architecture dependent.
I also reuploaded  hfs0.3.0.zip so it to include the "ia32" module.
I think anyway that it's better if I switch to a machine-independent version of the crc32 module. It is used only while creating ZIPs, and I think there will be only an acceptable increase in CPU usage. I can always reconsider this choice in the future.
Title: Re: a new beginning...
Post by: dj on December 31, 2021, 05:31:46 PM
Can you tell me what CPU are you running it on? Or is it a VM ?

Intel(R) Atom(TM) x5-Z8300  CPU @ 1.44GHz   1.44 GHz
Title: Re: a new beginning...
Post by: raybob on December 31, 2021, 06:43:06 PM
Hi Rejetto, just stopping by to say hi and happy holidays! The new rewrite looks like a cool project. I agree it's probably best to move beyond Delphi. It had a long and successful life. I hope you have fun writing the new version!

You might find it interesting to know that these days I am a professional software engineer and I'm proud to say that HFS and its template scripting is how I got my (unconventional) start.
Title: Re: a new beginning...
Post by: NaitLee on January 01, 2022, 06:50:37 AM
Wow, great... :D

I don't interested in Node for some reasons. But I wonder if there will be a template engine, just like the old classic HFS2.

I kinda like the Lisp-ish syntax, hacking around it makes fun. But others may don't think so...

Making a template engine based on other stuffs is well acceptable, as well as the community develops :)

If this is the case, please open some API or Plugin interfaces (at any time), thus we can make an interpreter for old templates...

Cheers~
Title: Re: a new beginning...
Post by: rejetto on January 01, 2022, 10:30:35 AM
Intel(R) Atom(TM) x5-Z8300  CPU @ 1.44GHz   1.44 GHz

ooooh, atom. Ok, so i get from your screenshot that my "npm..." suggestion did the job and now you have this other problem. I can see from the "hashing" message just before that it is trying to WRITE the file. So it successfully reads it but then cannot rewrite it. Can you make an attempt at modifying that file yourself and see if you can save it? If you can but HFS can't, check if it is running under limited permissions, like a different user. I will see to make a better error message in the meantime.
Title: Re: a new beginning...
Post by: rejetto on January 01, 2022, 10:42:06 AM
You might find it interesting to know that these days I am a professional software engineer and I'm proud to say that HFS and its template scripting is how I got my (unconventional) start.

wow, that's totally unexpected and amusing :D
let's have a coffee next time I stop by NYC
Title: Re: a new beginning...
Post by: rejetto on January 01, 2022, 10:55:56 AM
I don't interested in Node for some reasons. But I wonder if there will be a template engine, just like the old classic HFS2.

I will make something but I'm not sure what. I'm postponing the matter as we are at an early stage.
When plugin will be possible they will surely be javascript, and not the hfs2 scripting language.
Consider that all the "template" stuff at the moment resides in the "frontend" folder, and is a totally separated software that you may change or rewrite.
The frontend/template is calling server's API to build the final content. This is the new architecture.
The current state of the work doesn't allow you to replicate old scripting language, as it was server-side, while frontend is totally client-side.
Future plugins may add the server-side commands you miss.
I don't think we'll miss the old language, javascript on the server is so much more nice and powerful.
Title: Re: a new beginning...
Post by: dj on January 01, 2022, 11:53:36 AM
... So it successfully reads it but then cannot rewrite it. ...

Thanks. The folder was read-only. Now it works. :)

Next I'll test my template (https://rejetto.com/forum/index.php?topic=11754.msg1067169#msg1067169).
Need to learn typescript first (modified).


try also other themes (https://github.com/dj0001/hfs-template/tree/master/addons/themes) like live (https://github.com/dj0001/hfs-template/blob/master/addons/themes/Live_theme.diff.tpl)

Title: Re: a new beginning...
Post by: NaitLee on January 01, 2022, 04:20:27 PM
Few obstacles here in testing, but overall great ;)

OS: Manjaro
Environment: Node.js v17.2.0
Browsers: Firefox 96.0b3, Chromium 96.0.4664.93

Since exe is not needed here, I just take the hfs0.3.0.zip from release.

First node complains cannot find module './QuickZipStream'.
Seeking around, and found there's a quickZipStream.js in root folder.
So in filesystems like ext4 filenames are case-sensitive. Be aware of that :D

By correcting the letter-case and specifying a port (other than 80), it started successfully.

Then a google stuff stalking around:
Code: [Select]
<link href="https://fonts.googleapis.com/icon?family=Material+Icons+Outlined" rel="stylesheet" id="iconsFile">
By blocking the request, the list loads blazing fast.
And, seems there's missing a CSS rule: #root { margin: auto; } ::)

By adding home folder to config.yaml, it is listed. There are many items, but listing is still that fast.

Without icons loaded it looks silly (for the long alt duplicate strings). Wish there can be a better (local) approach.

By the way, it is almost impossible for a normal user to edit the 244kb minified javascript to fit normal/special needs. Starting from source is tough.
... Yes I'm thinking about template again ::) no need to think too much, just go with our own pace :D
Title: Re: a new beginning...
Post by: rejetto on January 03, 2022, 05:04:36 PM
thanks for reporting the quick*.js problem. I reuploaded the release so that it's fixed.
Can you tell me why you removed the icons file ?
the strings in place of the icons are the way those icons work. The fact they appear is unwanted.
Not relying on the google server for the icons was already in the to-do.
ok for the margin:auto.

you should NOT try to edit the minified javascript.
They are not supposed to be edited for the time being.
The frontend will soon have some customization capabilities, I still need to understand what's really needed.
For those that need HEAVY customization, totally replacing the "frontend" folder will be an option.
Anyway, that should be the last option. Let's try to focus on customizing the default frontend without touching it.
Tell me what you would like to customize exactly.
Title: Re: a new beginning...
Post by: rejetto on January 03, 2022, 05:05:42 PM
Next I'll test my template (https://rejetto.com/forum/index.php?topic=11754.msg1066673#msg1066673).
Need to learn typescript first (modified).

I don't think you should learn typescript.
I want the default frontend to be customizable to some extent. Let's talk about your needs, as stated in my post above.
Title: Re: a new beginning...
Post by: rejetto on January 03, 2022, 11:20:54 PM
https://github.com/rejetto/hfs/releases/tag/v0.4.0-alpha

includes both the icons for NaitLee, and a first plug-ins system
Title: Re: a new beginning...
Post by: NaitLee on January 04, 2022, 02:32:02 PM
thanks for reporting the quick*.js problem. I reuploaded the release so that it's fixed.
Can you tell me why you removed the icons file ?

The lower-cased "quick" is found in 0.4.0. Also fix that :)
Oh right, all google services are banned in my locale, including the search engine, its resource api/cdn, and captcha...

For those that need HEAVY customization, totally replacing the "frontend" folder will be an option.
Anyway, that should be the last option. Let's try to focus on customizing the default frontend without touching it.
Tell me what you would like to customize exactly.

Yeah, this inspires me to go deeper... ::)
My goal is to make "old" templates (of HFS2) to be able to be used in this brand new version.
Because this project will develop in time, but the Delphi version will still have audience for a long time.
Why don't just cover them both :D
I don't like the so-called "compatibility" either. But this time it's not "compatible" but "universal", right ::)

So here it comes: the "Tradit-TPL" plan, it aims to add a layer to this new version to support legacy templates.
In attachment there's a WIP version that can do sections & few symbols. Of course macros are on-the-way.
It uses some concepts from PHFS. So we can just walk toward :D
Read the readme in archive and follow it to try.
If have no interest in it, just let the community take the job. :D

PS. Dynamic page and Ajax have different pros & cons. Selection is by one's preference.
PPS. I personally want to renew the development of my template but keep one codebase and some traditions of Throwback.



While making above work, I've found a possible bug in `frontEndApis.file_list`:

Argument `sse` is directly from url query, so it's string. Even when we pass `?sse=0` it is still true.
So may convert it to number along with `offset` and `limit`.

Cheers~
Title: Re: a new beginning...
Post by: rejetto on January 04, 2022, 02:54:43 PM
sorry for the lowercase, i fixed the zips.
I'm not sure how that shit survived, but i now cleared the "dist" folder and hopefully it won't happen again.
I'm not willing to support the old template system. It was conceived 20 years ago and I think we can have better things now.
The new system is totally different, and there's so much work to do going forward.
The line you say is correct, it means that when SSE is used then data is transmitted via sseSrv.send, not by returning it.
Title: Re: a new beginning...
Post by: rejetto on January 04, 2022, 03:02:07 PM
Argument `sse` is directly from url query, so it's string. Even when we pass `?sse=0` it is still true.
So may convert it to number along with `offset` and `limit`.

or you can just NOT pass it to have it falsy.
Title: Re: a new beginning...
Post by: rejetto on January 04, 2022, 03:27:09 PM
just to be clear, the fact that at the moment I don't plan to introduce compatibility with old templates doesn't mean I won't help you with your project.
I had a look at your sources. My suggestion is to change my sources for testing purposes only, but after you clearly identify your needs we should try to imagine it as a plugin to put in the "plugins" folder.
Apparently you may need to to totally replace the serveStaticFrontend.
If we want to play with expanding plugins capabilities we should do it possibly without passing by official releases distribution.
You may use git, or I may pass you files/changes privately.
Title: Re: a new beginning...
Post by: rejetto on January 05, 2022, 03:46:45 PM
https://github.com/rejetto/hfs/releases/tag/v0.5.0-alpha

@NaitLee have a look at the new plugin example, it may be what you need for your project.
Refer to the README file for details
Title: Re: a new beginning...
Post by: dj on January 07, 2022, 09:58:32 AM
@NaitLee have a look at the new plugin example, it may be what you need for your project.
Refer to the README file for details

Have you another example of the middleware plugin?
I don't make sense of it .
Can we manipulate the DOM?
Title: Re: a new beginning...
Post by: rejetto on January 07, 2022, 12:56:07 PM
middleware is server side.
DOM is client side.
if you need to manipulate the DOM you need something else.
anyway, the default frontend is a React application, I don't think you can freely mess with the DOM.
I suspect that those of you who want to keep the old methods may need a totally different frontend, completely replace the frontend folder.
The middleware thing is probably useless.
Title: Re: a new beginning...
Post by: rejetto on January 07, 2022, 03:13:10 PM
anyway, if you tell me about what are your DOM needs, i may think of something.
Of course you should first see if it's solvable with style alone.
Title: Re: a new beginning...
Post by: NaitLee on January 08, 2022, 09:04:15 AM
The middleware plugin feature is completely well... ;)

... But before I success I encountered a bug:
The function deleteModule in plugins.js is recursive,
but when a plugin have requires to Node/HFS native modules, a infinite recurse occurs.
Code: [Select]
plugin error importing test.js RangeError: Maximum call stack size exceeded
To reproduce, a single "require" to HFS native module in a valid plugin can trigger this.
So, only do recurse if it's a real "plugin" (or really need be deleted) and not deleted before.
(found this after debugging for half an hour :()

And, consider a event-driven plugin structure? We can do almost everything with dom addEventListener, and also event.preventDefault :)
Don't forget the old "event script", too :)
Title: Re: a new beginning...
Post by: rejetto on January 08, 2022, 09:41:02 AM
thanks for the bug report. I will work on it.
What was you exactly thinking for the events? Would loading your js in the page be enough for your purpose?
Title: Re: a new beginning...
Post by: rejetto on January 12, 2022, 06:46:57 PM
i just published the "download counter" feature in form of plugin (disabled in config file)
Title: Re: a new beginning...
Post by: danny on January 13, 2022, 03:02:13 PM
Because somebody probably will use this on Gigabit,

I'd like a rights flag "SimpleView"
so that if "SimpleView" is assigned to a user, they would see a view that looks 'easier' like Stripes.tpl
. . . because not many users need to manage the server. . .  The majority just wanted files/content.
P.S. 
A "SimpleView" flag assigned to a folder or guest, could be very useful for public content.   
Not only for appearance, but also because a simple view can be ~5x more robust for high traffic.
P.P.S.
Additional request:  WatchDog feature included (to restart the server app, just in case it went unresponsive for x minutes).
Title: Re: a new beginning...
Post by: rejetto on January 13, 2022, 03:42:27 PM
hi Danny, do you mean gigabit as speed of your connection? if positive, i'm using a gigabit, but i don't see how it is related. Normally it's people with slow connections who has special needs.

i don't know if you saw the new template, but is very similar to the one of hfs 2.4 . Is that simple enough?
if negative, could you tell me what you would like to see removed ?
per-folder template could be a nice feature.
per-user template could be as well, but it means you first have to login, and that means you'd do it with another template. Sounds bad.
a good watchdog should not be in the server, but outside of it. I guess a good watchdog has already been made, and will work with hfs with minimal configuration.
Title: Re: a new beginning...
Post by: danny on January 13, 2022, 05:51:52 PM
i don't know if you saw the new template, but is very similar to the one of hfs 2.4 . Is that simple enough? if negative, could you tell me what you would like to see removed?
Not simple enough for file server.  Because most users don't need to see server management menu. 
So, not really stuff to remove; but, there is stuff to Hide (to clear/clean the view, for the majority of users). 
 
The need is for a switchable view: 
Simple-Grandma mode (like Stripes), in light colors
Server-Manager mode (like hfs2.4),  in dark colors
. . . and default public/guest to use simple-grandma mode (it is right to use the Login button for mode/view switch). 

Per circa 1999 Orangebook and in regard to the Zenworks security module, the original background-color view switch was lightblue for basic users, darkblue for printer/backup manager, darkred for Administrator and lightgreen for inspector (business owner could see all but not accidentally disable the server). . . At login, the desktop icons as well as the program menu options would populate (or de-populate) to fit the user's access/experience level. 
Today, I think that can be translated into lightblue (colors like twitter, facebook, openmediavault, Stripes.tpl) for basic users, and then a dark theme for server managers. 

An example of menu for simple-grandma mode: 
HFS File Server
[sort][................................searchbox.............................][login]
A small thin menu, so that basic users (especially guest/public) are more likely to notice the file-listing/content, primarily. 
Title: Re: a new beginning...
Post by: rejetto on January 13, 2022, 05:56:14 PM
can you tell me what is "server management menu" that you want to hide? i still fail to see
Title: Re: a new beginning...
Post by: danny on January 13, 2022, 06:11:47 PM
can you tell me what is "server management menu" that you want to hide? i still fail to see

Just need a simple/grandma view, with much smaller-size simpler menu for guest/public.
Would also be good if 'simpleview' could be a user/folder rights flag option (and the default for guest/public). 

The default template has what I want to see; however, it may confuse my grandma/son/brother/guests too, because they don't own servers.  It is because of the purpose-difference:  I might like to manage the server; however, they might just want files/content.   So, there is 2 different purposes and thus need of 2 different views.
Title: Re: a new beginning...
Post by: rejetto on January 13, 2022, 10:51:05 PM
you can hide stuff and change the look to some degree with css.
If you can't get what you want this way we can talk about it, but it must be more specific than "simple".
Of course completely replacing the frontend is an option, but I want to consider more customization possibilities.
Those who want to stick with the "template" concept at the moment have no luck, but maybe in the future you'll have NaitLee plugin :)
of course we are talking about HFS 3 here...
Title: Re: a new beginning...
Post by: rejetto on January 14, 2022, 09:47:22 AM
Also, I think standard template needs to go on a weight-reduction diet on scale of 3x~5x smaller and easier to work on. 

the size is acceptable at this stage where we are still missing important features.
Once I activate gzip transmission (doing it these days) it is 100KB + 150KB font-icons.
It loads in 3.5 seconds on a 3G connection and 1 second on my phone.
After first time it doesn't need to load anymore because it will just load the pure list of files without any html attached.
Every folder change is likely to be 5KB.
I don't see anything critical in the size. Anyway, in the future I (or other people) may spend time in trying to reduce the size, it's just not a priority.
Working on the icons size may be the best next move, i guess.
After that, maybe trying to switch from react to preact. That may save up to 27KB (gzipped) (https://gist.github.com/Restuta/cda69e50a853aa64912d).

It's not even a problem of "it's hard to edit it" because you almost CAN'T do it. You are not supposed to, because it's against the kind of technology used there. That's why I'm trying to do the job through plugins.
Editing the template was a big plus of HFS2, but also a huge problem: once people customize their template for the sake of customizing a simple word/color/icon they are lost (almost always), they don't get updates in the default template anymore, they go out of sync with consequences on functionality but also on security. Default template (hfs2) had nasty security bugs in the past, because it contains also dangerous commands, like delete.

Quote
Howabout a new thread for HFS3x user interface contest?  Fun! 

you are free to do it, but mind we are still in a experimental phase and things can change a lot.

No body is going to delete HFS 2, it is there for those who like it that way.
HFS 3 is actually a new software with very similar goals. I also considered rebranding it, and I don't exclude doing it in the future.
Think of the leap between windows3 and windows95.
Title: Re: a new beginning...
Post by: danny on January 14, 2022, 02:45:11 PM
...It's not even a problem of "it's hard to edit it" because you almost CAN'T do it. You are not supposed to, because it's against the kind of technology used there. That's why I'm trying to do the job through plugins.
Editing the template was a big plus of HFS2, but also a huge problem...with consequences on functionality...
I think that the plugins method in HFS3 is a great improvement.

Comparison, I think:
HFS2x standalone templates = get the new feature you wanted but lose 3 more, or
HFS3x plugins = get the new feature you wanted, without losing other features. 

That is a lot different.  Thanks!!

Title: Re: a new beginning...
Post by: rejetto on January 14, 2022, 02:48:34 PM
yeah, of course we have a long road ahead to understand what's needed, for plugins, to be able to do their job.
and it's cool that someone may make a plugin to work with old templates, nonetheless.
Title: Re: a new beginning...
Post by: rejetto on January 16, 2022, 10:56:13 AM
https://github.com/rejetto/hfs/releases/tag/v0.6.0-alpha

I'm still producing "releases" that probably need some extra care, but invite the braver of you interested in following progress to use unzip this dynamic archive of my sources:
https://github.com/rejetto/hfs/archive/refs/heads/main.zip
but using git is also a nice option

i hope the exe file works good, but it's not the option i personally love
Title: Re: a new beginning...
Post by: dj on January 16, 2022, 11:12:40 AM
a new plugin: fileicons
(possibly obsolete with v0.6 )


Modified:
I did something wrong with v0.6 (screenshot)

Modified2:
copy dist folder one folder up to work
but plugins don't work (you need to enable plugin in config.yaml)


Modified3:
the audioplayer from the bundle (https://rejetto.com/forum/index.php?topic=11754.msg1067169#msg1067169) also works with hfs3(v0.6) default template
Title: Re: a new beginning...
Post by: rejetto on January 16, 2022, 05:43:10 PM
maybe there's a problem with the folders structure.
The new arrangement is that config files are outside of 'dist', and from outside you should run 'node dist'.
also plugins is outside of dist.
i tried the zip on a linux (WSL) and it worked just as it was, but i have overlooked something.
If you can't find how to solve you can contact me privately and I will try to help you.
LMK
Title: Re: a new beginning...
Post by: rejetto on January 16, 2022, 08:56:26 PM
i've noticed several problems with the previous distribution, so i've worked hard to try to solve them all.
https://github.com/rejetto/hfs/releases/tag/v0.6.1-alpha

i think the exe version can be a good solution for most users now.

a big change is that the frontend folder is "outside" now.
the main purpose is for full replacement (if you have another), it is still not designed to be edited.
Customization of the default frontend is to be done through plugins.
Title: Re: a new beginning...
Post by: NaitLee on January 17, 2022, 06:04:04 AM
The ISP here seldomly allows me (and other people) to access GitHub, whether I can access HFS repository is by luck.
If possible please mirror the repo to somewhere like GitLab (https://docs.gitlab.com/ee/user/project/repository/mirror/#repository-mirroring), then ones here can have another way...
GitLab can also be self-hosted.
I'm moving to GitLab also.



I see the directory structure changed.
But it made me confused: should I access HFS libs by simply importing the original files?
In the last 2 days I structured my tpl plugin (with/for hfs 0.5), it uses this:
Code: [Select]
import process_1 from 'process';
import path_1 from 'path';

// Workaround for my workspace, which is symlinked to plugin directory.
const NODE_PATH = process_1.cwd();
export function absRequire(path: string): any {
    return require(path_1.join(NODE_PATH, path));
}
This is used to solve many things, with absolute cwd.
And with it I am able to import HFS libs, and use them directly.

While we are exposing some apis in another way (like the const api = exports.api = {}), which means we'd better just use it.
But in theory it's always not enough, and if there's something missing, I will directly import HFS libs then use stuffs inside, without nothing bad.
This way such exposing became useless :'(

In my case:
Code: [Select]
import { absRequire } from './absRequire';
const frontEndApis_1: HFSFrontEndApis = absRequire('frontEndApis').frontEndApis;
const config_1: HFSConfig = absRequire('./config');
These are before hfs 0.6. They work just well.

So the suggestion is, simply make HFS libs themselves useable in a standard way, then let plugin makers take knowledge from some kind of documents (or source code)
EDIT: "including" the built-in stuffs to a central lib is also an option, and this can keep interfaces stable (not suddenly changed in the future)

PS. I personally feel the exports.api with setTimeout uncomfortable. So I don't want to use it :(
Title: Re: a new beginning...
Post by: NaitLee on January 17, 2022, 09:34:17 AM
Some random thoughts... :)

I see this:
Code: [Select]
this.data = data = { ...data }

While I can understand changes to plugin, this "cloning" may not as good as think.
It's better to consider the "prototype" in JavaScript.
Again about the "api injection" technique, consider other acceptable methods :P

Also before HFS 0.6, there's this in my tpl plugin:
Code: [Select]
var traditTpl = function(ctx) { template.serve(ctx); return true; }
traditTpl.prototype.middleware = function(ctx) { template.serve(ctx); return true; }
// ...
module.exports = traditTpl;
I just think it maybe useful, so wrote this by casual. And hfs 0.6 really want a "middleware" attribure.
But this didn't work -- the object cloning doesn't clone the prototype.

... Wish these make some sense :D

Tip: manipulate prototypes with Object.setPrototypeOf(target, object) etc.
PS. I don't afraid of changes. I just want to keep usual practice and keep things as-good :)
Title: Re: a new beginning...
Post by: rejetto on January 17, 2022, 09:56:21 AM
The ISP here seldomly allows me (and other people) to access GitHub, whether I can access HFS repository is by luck.
If possible please mirror the repo to somewhere like GitLab (https://docs.gitlab.com/ee/user/project/repository/mirror/#repository-mirroring), then ones here can have another way...

can't you mirror it yourself by providing gitlab the address of my repo?
Anyway, with some research i've found this address. I hope it may be useful to you
https://github.123vip.workers.dev/-----https://github.com/rejetto/hfs/releases

Quote
I see the directory structure changed.

i try to keep this as infrequent as possible of course

Quote
But it made me confused: should I access HFS libs by simply importing the original files?

i think I should consider every plugin real need, and see if I can offer a way to solve it without it depending on HFS sources structure.
As a fallback a plugin can consider importing HFS sources, but it's a risk, especially when we are in a fast evolving situation like now.

In the last 2 days I structured my tpl plugin (with/for hfs 0.5), it uses this:

Quote
This is used to solve many things, with absolute cwd.

cwd is not a good solution IMO, as it is not directly related to the sources but to the runtime.

Quote
While we are exposing some apis in another way (like the const api = exports.api = {}), which means we'd better just use it.

exactly, that should be your first place where to look. And if you don't find what you need you should tell me, so we can discuss it.

Quote
But in theory it's always not enough, and if there's something missing, I will directly import HFS libs then use stuffs inside, without nothing bad.

it's not nothing. You depend on my sources structure, which I may be forced to change. While I will make an extra effort to keep plugins api still.

Quote
So the suggestion is, simply make HFS libs themselves useable in a standard way,

standard means that I should not change my sources so your import will always work? this is practically impossible :)

Quote
EDIT: "including" the built-in stuffs to a central lib is also an option, and this can keep interfaces stable (not suddenly changed in the future)

It's not just a matter of where things are and what name they have. It's not enough. Your suggestion is not feasible.

Quote
PS. I personally feel the exports.api with setTimeout uncomfortable. So I don't want to use it :(

I tried other solutions before this, and they were worse, then I got this.
If you have a better solution I will be happy to consider it. I'm not in love with this either so I won't try to defend it.
But what you just suggested is bad and doesn't take into account real world needs.
Title: Re: a new beginning...
Post by: rejetto on January 17, 2022, 11:39:29 AM
While I can understand changes to plugin, this "cloning" may not as good as think. It's better to consider the "prototype" in JavaScript.

i'm happy to see that you know this case could make use of prototypes. :) It's a concept most javascript programmers ignore, but I've always liked.
In THIS case anyway it may be better to keep shallow-cloning, as (1) it is easy to read for most programmers, (2) there's no actual difference in performance, (3) I should reconsider the rest of the code as they are not equivalent (for a start, the "delete" won't do what I need, and there may be other consequences in the rest of the source).

Code: [Select]
var traditTpl = function(ctx) { template.serve(ctx); return true; }
traditTpl.prototype.middleware = function(ctx) { template.serve(ctx); return true; }
// ...
module.exports = traditTpl;

While this may work, the use it makes of prototypes seems pointless to me. Maybe you have some use of it that I don't see here.

Quote
I just think it maybe useful, so wrote this by casual. And hfs 0.6 really want a "middleware" attribure.
But this didn't work -- the object cloning doesn't clone the prototype.

you are not supposed to do like that.
there's a simple example provided, and it's very simple:
exports.middleware = function(ctx) { }
Title: Re: a new beginning...
Post by: NaitLee on January 17, 2022, 12:42:55 PM
ok, let's try to keep plugins "subjective"...

Now that apis for a plugin are manipulated by HFS, and many more sooner-or-later,
so whether a plugin is ready is determined by HFS.
Why doesn't HFS finally tell the plugin is ready? it is as easy as calling init() on the plugin module, if there is one.
Of course the procedure of init() is by plugin developers :) seems better than a mysterious setTimeout thread trick
I accept the "exports.api" if this kind of objective-or-subjective is dealt well :)

Also consider asynchronously initialized plugins. Await one of it's the case and it's necessary.
Consider telling HFS it's async / should be awaited (or other characteristics) by exposing something (like isAsync: true) in module.exports.

I think we still need to tell plugins where are builtin files, for edge cases.
Even if it means "at my own risk" or "not officially supported", it's a way to play with HFS in a kinder method.
Of course we can limit it with something like debug flags... Just in completeness.
... If really still don't want to do this, just omit these :D

btw I choose to import builtin files (as a fallback layer of exports.api) for now for my tpl plugin, for maximum efficiency of development & test cycle
Title: Re: a new beginning...
Post by: rejetto on January 17, 2022, 01:47:51 PM
i like the .init suggestion.
About the async, it's ok that you define your init as async.
I will await the init so we are covered for the future. At the moment there's nothing done synchronously after that.

About importing HFS sources.
When executing "normally" with node you probably can require('../../src/config')
like this
Code: [Select]
const { getConfig } = require('../../src/config')
console.log('ciao', getConfig('port'))

but this won't work with exe distributions (just tried), as I noticed it virtualize sources position.
So my idea is that this will be the way to go from next version
Code: [Select]
exports.api = {}
exports.init = function() {
const { getConfig } = require(exports.api.srcDir + '/config')
console.log('ciao', getConfig('port'))
}

Good? Better ideas?
Title: Re: a new beginning...
Post by: NaitLee on January 17, 2022, 03:49:07 PM
This may enough for most others. But in my own case I should consider if srcDir is/can be absolute. ::)

Here is a unix-like environment.
My workdir is at ~/Documents/Tradit-TPL, I just symlinked it to ~/Applications/hfs0.6.0/plugins/Tradit-TPL
This way I don't need to move the workspace around to update hfs. I just create a new symlink to new version.

But when the plugins are imported by HFS/Node, the symlink is resolved by Node,
then my plugin scripts can't import HFS libs with a relative path for/from HFS/Node runtime: nothing is around the real workspace.

And that's why previously there's an "absRequire" thing...

Sure I can define my own development config (as in-plugin debug configs), if I can make everything well by/for myself :)

btw is there any convenient technical methods on Windows/other platforms for developing hfs plugins (or hfs itself)?
If really no, we may implement some in HFS level, to help developers :)

PS. seems my posts are "ignoring" normal users that just cares file sharing. I'll try my best to focus on the main target :)
But, I have much enthusiast to investigate HFS3, plugins, and macros... I want to grow and be well...
Title: Re: a new beginning...
Post by: rejetto on January 17, 2022, 04:38:15 PM
I don't see the problem in ensuring you get directly an absolute path. Seems easy.
It's cool someone is playing with it.
Title: Re: a new beginning...
Post by: mandoz on January 17, 2022, 07:08:11 PM
Hi guys,
I would like to try the new version but I have some problems ....
i use a pc with windows 10 pro 64. i tried as a simple user and as  administrator
thank.
Title: Re: a new beginning...
Post by: rejetto on January 17, 2022, 07:14:01 PM
yes, it seems to be working, but you are right: it doesn't tell you what to do.
open your browser and type "localhost" in the address bar.
I will add this message to the next version :)
Title: Re: a new beginning...
Post by: mandoz on January 17, 2022, 07:28:09 PM
Hi rejetto,
I did it. the browser opens a normal search page
does not open hfs3
Title: Re: a new beginning...
Post by: rejetto on January 17, 2022, 07:54:00 PM
i have no idea: if it says listening on port 80 it is supposed to work, but further investigation is complicated.
you could verify that the port is actually open. it can be done in several ways. An easy one is running: telnet localhost 80
if a black window without text opens, then the port is open.

also, can you post a single screenshot with both your browser on localhost and hfs window running?
Title: Re: a new beginning...
Post by: mandoz on January 17, 2022, 08:04:54 PM
maybe I understood!!
it seems not to work with portable software
works with installed software like edge, opera
it does not work with internet explorer
it's possible?
Title: Re: a new beginning...
Post by: rejetto on January 17, 2022, 08:42:05 PM
Internet Explorer? On Windows 10?  Seriously? 😆

Hfs is not compatible with it and it will probably never will.
Title: Re: a new beginning...
Post by: mandoz on January 18, 2022, 10:03:51 AM
sorry rejetto.
i.e. it wasn't a request, I thought it might interest you.
I am a user of portable programs ....
Title: Re: a new beginning...
Post by: rejetto on January 18, 2022, 12:16:47 PM
ciao mandoz, don't worry, i was just surprised someone would want/need to use IE on win10
and then i declared it won't work.
i'm using portable chrome for testing purposes (compatibliity), so it's not a matter of being portable.
peace
Title: Re: a new beginning...
Post by: rejetto on January 18, 2022, 05:49:04 PM
...and HFS 3 just got https support :)
i hope we'll be able to integrate letsencrypt automatic generation, maybe as a plugin
Title: Re: a new beginning...
Post by: dj on January 19, 2022, 09:49:14 AM
dark theme
make sufficient contrast ratio

Code: [Select]
:root .theme-dark a {    color: #fff9;}
Modified: alternativ #94b2d1
Title: Re: a new beginning...
Post by: rejetto on January 19, 2022, 11:28:04 AM
in the paste i've met issues using transparency for fonts, for the sake of shading, and in this case it's easy to decided a opaque code for the final color.
#8ac may do the job
Title: Re: a new beginning...
Post by: NaitLee on January 20, 2022, 01:27:03 PM
I've found a github repo mirroring service for me: https://ghproxy.com/https://github.com/rejetto/hfs/
This works on git clone (and pull) but not a browser. Though It's enough :D
So I decided to pull & build HFS3 by myself, if there's an update.

Followed instructions in readme.md, the build result is running well ;D
~/hfs $ cd dist && node src

... while there are notable alerts from npm:
Code: [Select]
22 vulnerabilities (3 low, 18 moderate, 1 high)

This is the output of npm audit, before fixing:
Code: [Select]
# npm audit report

follow-redirects  <1.14.7
Severity: high
Exposure of sensitive information in follow-redirects - https://github.com/advisories/GHSA-74fj-2j2h-c42q
fix available via `npm audit fix`
node_modules/follow-redirects

1 high severity vulnerability

To address all issues, run:
  npm audit fix

Of course I ran npm audit fix

But if I try building again, in the procedure the "22 vulnerabilities" alert is still there.

Auditing again will output found 0 vulnerabilities
Should it be true or false ???
Title: Re: a new beginning...
Post by: rejetto on January 20, 2022, 01:38:45 PM
ignore those warnings, because they involve libs used only by the dev environment.
if you "npm audit --production"
you'll get "found 0 vulnerabilities"

i'm including this in the instructions
Title: Re: a new beginning...
Post by: rejetto on January 21, 2022, 02:43:12 PM
here goes https :)
https://github.com/rejetto/hfs/releases/tag/v0.7.0-alpha
Title: Re: a new beginning...
Post by: rejetto on January 23, 2022, 02:12:10 PM
https://github.com/rejetto/hfs/releases/tag/v0.8.0
pagination will allow you to work even with 30k files long lists
forbid listing of a specific folder
button to invert selection
Title: Re: a new beginning...
Post by: mandoz on January 24, 2022, 07:18:17 PM
hi rejetto,

Is it possible that hfs3 ipv6 address is different from hfs2 ipv6?
it would seem shorter ...
Title: Re: a new beginning...
Post by: rejetto on January 24, 2022, 10:32:57 PM
i just checked and it was the same to me
Title: Re: a new beginning...
Post by: TEA-Time on January 24, 2022, 10:54:59 PM
Hi mandoz,

I know hardly anything about IPv6, but I do know that parts of it can be abbreviated, which probably explains why it's "shorter".  See the "Address representation" section on this Wikipedia page (should take you straight there):

https://en.wikipedia.org/wiki/IPv6#Address_representation
Title: Re: a new beginning...
Post by: NaitLee on January 29, 2022, 02:42:57 PM
My tpl plugin needs to get file list, better with streaming :)

I see the file_list function in api.file_list.ts, without "sse" parameter I can get it directly.
But first it's not in exported api, and more important, this method seems won't stream the list but do one big shot.

I also noted the onDirEntry which a plugin can define. Seems a good point.
But, is it for frontend (exclusively)? Should I use it for a middleware plugin?

Also, should my plugin be able to call internal apis like authentication/permission check, or make an http redirect/do other hacks?
... or simply let HFS itself handle them properly ::)
Title: Re: a new beginning...
Post by: rejetto on January 29, 2022, 09:37:03 PM
onDirEntry is in case you want to manipulate the list in the backend, not in frontend.
I think what you need is walkNode.
Title: Re: a new beginning...
Post by: rejetto on February 07, 2022, 09:35:14 AM
https://github.com/rejetto/hfs/releases/tag/v0.9.0

admin interface, with real time connections monitor
Title: Re: a new beginning...
Post by: rejetto on February 08, 2022, 05:09:48 PM
in next version plugins' api will get a breaking change:
the way to get the api object will be as parameter of the "init" function.
I think this is cleaner.

Also, I've noticed that in exe distribution the 'require' doesn't work. To solve this, plugins will get api.require in the api object.
Title: Re: a new beginning...
Post by: rejetto on February 10, 2022, 07:07:36 PM
https://github.com/rejetto/hfs/releases/tag/v0.10.0
Title: Re: a new beginning...
Post by: rejetto on February 13, 2022, 08:20:33 PM
https://github.com/rejetto/hfs/releases/tag/v0.11.0
Title: Re: a new beginning...
Post by: NaitLee on March 17, 2022, 07:10:09 AM
For newest 0.14.2 code, I should manually compile the "shared" folder in order to continue build-all.
cd shared && npx tsc && cd ..
Yes it's easy. Put it in the build-all process :D

Current HFS 3 version successfully built and running on my android phone, with Termux :D
Title: Re: a new beginning...
Post by: rejetto on March 17, 2022, 09:26:34 AM
thanks for your help!
and it's nice to have some feedback from time to time and know that people are using it. I'm struggling, with my full time job, to find the time to progress. Wish I had more.
Android? Unexpected surprise :D

link for the folks
https://github.com/rejetto/hfs/releases/tag/v0.14.2
Title: Re: a new beginning...
Post by: mandoz on March 19, 2022, 01:50:56 PM
hi rejetto, i'm trying hfs3 0142 with more dns active simultaneously .... all work (3) well.
congratulations for your job. i confirm android ok
Title: Re: a new beginning...
Post by: rejetto on March 23, 2022, 10:40:35 AM
thanks mandoz!
se ti serve contattarmi direttamente fallo pure
Title: Re: a new beginning...
Post by: gintibande on April 23, 2022, 12:04:09 PM
I don't interested in Node for some reasons. But I wonder if there will be a template engine, just like the old classic HFS2.
mobdro apk (https://get-mobdro.com/home/)
Title: Re: a new beginning...
Post by: NaitLee on April 23, 2022, 12:25:50 PM
I don't interested in Node for some reasons. But I wonder if there will be a template engine, just like the old classic HFS2.

It's a very interesting coincidence that I've said something very similar (https://rejetto.com/forum/index.php?topic=13506.msg1067163#msg1067163) before ::)
The difference is that I took the opportunity to make one out.

While I've already done an engine in my PHFS, I want a totally new start.
And that means it will take some time...

EDIT: it's actually the same sentence. I'm wondering if this is bot...
Title: Re: a new beginning...
Post by: mandoz on April 24, 2022, 05:16:18 PM
hello rejetto,

hfs 3018. is possible to know from the admin panel
internal and external ip address - more personal dns reachable

thank you
Title: Re: a new beginning...
Post by: sightshooton on June 06, 2022, 01:00:29 PM
I agree it's probably best to move beyond Delphi. It had a long and successful life. I hope you have fun writing the new version!

19216811.bid (https://19216811.bid/)
panorama charter com (https://panoramacharter.ltd/)