rejetto forum

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - rejetto

Pages: 1 2 3 ... 888
1
:) good luck

your gitlab link says Page Not Found

2
HFS ~ HTTP File Server / Re: a new beginning...
« on: Yesterday at 08:42:05 PM »
Internet Explorer? On Windows 10?  Seriously? 😆

Hfs is not compatible with it and it will probably never will.

3
HFS ~ HTTP File Server / Re: a new beginning...
« on: Yesterday at 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?

4
HFS ~ HTTP File Server / Re: a new beginning...
« on: Yesterday at 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 :)

5
HFS ~ HTTP File Server / Re: a new beginning...
« on: Yesterday at 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.

6
HFS ~ HTTP File Server / Re: a new beginning...
« on: Yesterday at 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?

7
HFS ~ HTTP File Server / Re: a new beginning...
« on: Yesterday at 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) { }

8
HFS ~ HTTP File Server / Re: a new beginning...
« on: Yesterday at 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, 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.

9
HFS ~ HTTP File Server / Re: a new beginning...
« 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.

10
HFS ~ HTTP File Server / Re: a new beginning...
« 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

11
HFS ~ HTTP File Server / Re: a new beginning...
« 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

12
Bug reports / Re: Possible vulnerability
« on: January 14, 2022, 06:52:49 PM »
yes, you can create it yourself as a simple text file inside the program directory, but you can also Menu > other options > edit event scripts (it's at the bottom)

13
HFS ~ HTTP File Server / Re: a new beginning...
« 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.

14
Bug reports / Re: Possible vulnerability
« on: January 14, 2022, 10:14:23 AM »
you may not find any security specialist on this forum, thus my suggestion is google for vulnerabilities and look at results of specialized websites that should also report what versions are affected.
A good website would also report what version is known to fix the problem.
This is a more effective way of knowing that those attacks are not effective. Still annoying you in the logs.
In most cases these bugs are reported in an "ethic way" by security specialists, privately to the software producer, giving the time to fix the problem before the bug is made publicly known. And that's what have happen so far with HFS. It implies those bugs are supposed to be fixed in collaboration and normally verified by the same person who has discovered the problem. I once again wanna thank these people who I see as contributors of the project.

I think the "any macro marker" command is good to avoid spamming your logs. And that's all you need, i guess.
The old bug (long fixed) was with regular-expression lib, and that command is using just that.
Just for the sake of conversation, if for some strange reason I was forced to use an old vulnerable version, I would try to protect it using the {.pos.} command instead.
But it's nice that I don't have to.
Also because I'm already using sweet HFS 3 :D

15
HFS ~ HTTP File Server / Re: a new beginning...
« 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).

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.

Pages: 1 2 3 ... 888