xavi/slcl, branch test-multiform

WIP bump libweb

2024-01-20T00:20:20+00:00

README.md: Update according to thumbnail generation

2023-11-24T01:08:42+00:00

Display thumbnails, if available

2023-11-24T01:08:42+00:00

Add thumbnail generation tool

2023-11-24T01:08:41+00:00

This new application runs separately from slcl and communicates with it via a named pipe. When files are added/removed to/from the user directory, slcl shall write to the named pipe. Then, this new tool shall process incoming entries and generate or remove thumbnails accordingly. Such thumbnails are stored into a new directory inside the database directory, namely thumbnails/, which replicates the same structure as user/.

main.c: Add -m command line option to open a named pipe

2023-11-24T00:54:12+00:00

This write-only named pipe is meant to inform other processes about files that have been added/removed to/from the user/ directory. The syntax is line-oriented and is described below. For added files: + For removed files: - Paths shall always be absolute. Examples: + /home/test/db/user/alice/a picture.jpg - /home/test/db/user/bob/essay.txt As reported above, this feature has been made completely optional so as not to introduce breaking changes. A new command line option, namely -m, is required to enable this feature.

auth.c: Make use of crealpath

2023-11-24T00:54:12+00:00

crealpath already provides a mechanism to determine the current working directory from getcwd(3).

Introduce crealpath

2023-11-24T00:54:11+00:00

crealpath (for "custom realpath") is a custom implementation of realpath(3) that aims to work similarly to GNU's realpath(1). This implementation is provided due to the following reasons: - Future commits will require extracting an absolute path from a relative path, and/or process relative components from a path, such as ".." or ".". - realpath(3) is defined by POSIX.1-2008 as a XSI extension, and extensions are generally avoided in this repository whenever possible. - Additionally, realpath(3) requires the file or directory pointed to by the path to exist, which might not always be the case for slcl. - auth.c uses its own implementation to extract a dynamically allocated string by repeatedly calling getcwd(3). Future commits will also require this future, so it makes sense to keep it on a separate component.

configure: Fix typo

2023-11-24T00:52:52+00:00

slweb was renamed to libweb some time ago: commit 28ae865e5ecad9b398ac21fa148fc4b93c987226 Author: Xavier Del Campo Romero Date: Tue Oct 10 23:43:47 2023 +0200 Apply slweb renaming to libweb

.gitignore: Ignore only ./Makefile

2023-11-24T00:52:00+00:00

Future commits might introduce Makefiles on other directories that should not be ignored.

Bump libweb

2023-11-24T00:38:51+00:00

The following commit should increase performance for slcl: commit b0accd099fa8c5110d4c3c68830ad6fd810ca3ec Author: Xavier Del Campo Romero Date: Fri Nov 24 00:52:50 2023 +0100 http.c: Unify read operations So far, libweb would perform different read operations depending on its state: - For HTTP headers or request bodies, one byte at a time was read. - For multipart/form-data, up to BUFSIZ bytes at a time were read. However, this caused a significant extra number of syscalls for no reason and would increase code complexity, specially when parsing multiform/form-data boundaries. Now, http_read always reads up to BUFSIZ bytes at a time and process them on a loop. Apart from reducing code complexity, this should increase performance due to the (much) lower number of syscalls required.