Just posted: August progress report for #dropserver
This was primarily a vacation month but I started work on app changelogs which was interesting to think about.
https://olivierforget.net/blog/2023/dropserver-progress-august-2023/
I'm working on adding release notes (aka changelogs) to app packages in #Dropserver.
As usual I like to look at other platforms to see how they present things. It's interesting that the Google Play store buries the latest change, and doesn't allow you to see previous changelogs (why??) while #iOS embraces the changelog and presents the log in a pleasant and useful way.
Google may have even tried to get rid of them altogether: https://www.androidpolice.com/google-play-store-app-changelogs-coming-back/
What other platforms do changelogs well?
#Blog post: #Dropserver progress report for July 2023
https://olivierforget.net/blog/2023/dropserver-progress-july-2023/
In August I'll be taking some time off π΄. Back at it in September.
This "Review icon update" screen noticed by @rgegriff is relevant to the work on app packaging I was doing just recently.
Changes between versions can signal to the user that the app may not be good to keep around. It's the platform's job to highlight these changes.
In #Dropserver I highlight name, and license changes.
Not clear how to implement for icon though. File hash would trigger on compression change. Image "similarity" is harder to implement but this motivates me to look into it.
Adding a table of app migrations in the "new app" view in #Dropserver? Easy.
Aligning the text in the thead with the baseline of the label to the left of the table? Impossible (at least for me).
I could try all kinds of variations of #CSS flex box and grid and all kinds of other tricks, but that would eat up the rest of the morning.
So it's ugly. So it goes.
"So the only path for creating a web app is to still run a *service*. Which means figuring out monetization, authentication, sensitive user data storage, abuse prevention, maintenance, uptimeβ¦. Gah."
This is why I'm creating #Dropserver. There are many very talented devs with good ideas out there, but if it's a #webapp type of thing, they can't share their creation unless they make a service out of it. But that's a whole 'nother thing many won't touch.
https://mastodon.gamedev.place/@jonikorpi/110777129647669463
Installing a personal web service on #Dropserver: in the gif below it takes about 20 seconds* from start to interacting with the running web-app as the logged in user.
I can still improve this by eliminating some unnecessary interactions.
* in actual use it will take a bit longer: I had to do this a few times bc I fumbled, as a result the code was cached by @deno_land so the initial run was very fast.
I'll describe what's going on in the gif in the post below.
Finally released version 0.11.0 of #dropserver
This brings the ability create app packages (via the ds-dev helper program) and use these packages on a Dropserver instance.
This is the "packaging" part of "packaging and distribution". Next I work on distribution. Then I'll put my existing apps out there and you'll actually be able to use all this. π
I also improved the #UI a fair bit.
Dropserver is an application platform for your personal web services. https://dropserver.org/
Blog post: #Dropserver progress report for mid-April to June.
https://olivierforget.net/blog/2023/dropserver-progress-june-2023/
This is a long one that covers most of my work on application packaging. I hope to write these monthly now, so future ones will be less epic π
PS: https://dropserver.org is an application platform for your personal web services
#dropserver #opensource #development
Following up on yesterday's post on safely handling compressed archives in #Dropserver:
https://social.tchncs.de/@teleclimber/110533072014783603
I updated the code where it handles tar-gz app packages to count space used as it decompresses and writes to disk and it bails if over limit.
Size checked:
- from tar Header (not trustable but it's there)
- during io.Copy
- after copy is complete
https://github.com/teleclimber/Dropserver/commit/931d5beb1cfa65a5475614e9ae360bbd62354765
I wrote tests but haven't thrown a real bomb at it. Not sure how to do that safely.
1/
Inspired by @dansup 's post on (not) handling zip files on the PixelFed server I took some time to dig into how I will handle compressed archives in #Dropserver.
https://mastodon.social/@dansup/110531929329993851
I am currently working on app packaging, so the tar-gzipped app files are what I'm leaning into right now (I also accept zip files for data restore, but that ill have to be dealt with separately, though probably using the same principles.)
1/
I got frustrated yesterday when my personal #Dropserver instance stopped responding to some requests (the ones that involve an app sandbox).
But then I realized it had been running continuously for almost two months, it's alpha software that I make changes on constantly, and it had been reliably serving requests for my shopping list app, the leftovers tracking app, and my personal note taking app and others non-stop and without any noticeable issue every day for nearly two months.
So π
I'm going to let app devs declare an "accent-color" in their #Dropserver app manifests. It's a very cheap, easy and safe way of giving apps more personality inside the Dropserver UI.
I use a lib to parse the color and regenerate it using a CSS color parsing library to prevent an injection attack.
It won't affect accessibility because I'm not using the color for text foreground or background.
(Note: Davros is not a DS app, I borrowed it from #Sandstorm to play w/ full-bleed icon in #PenPot).
#penpot #sandstorm #dropserver
A month ago I wondered if #Dropserver should support "Single File Apps". (https://social.tchncs.de/@teleclimber/110216573477447480) Some thoughts, after a month of working on app packaging:
SFAs don't make a lot of sense for Dropserver apps. Most will include some sort of font-end (whether it's plain HTML or an SPA) in addition to the backend code, which implies additional files: #HTML templates, #CSS stylesheets, #JS, etc...
I was trying to make it easier to publish an app, but if the app is neutered there is no point.
1/
I'm less thrilled about the way "secondary indexes "work". You basically duplicate your data and store them at different keys. Yay? Looks labored and possibly inefficient from a disk space pov. We'll see.
https://deno.com/manual@v1.33.1/runtime/kv/secondary_indexes
Yet all-in-all I'm very happy to see this in Deno. Will make a big difference for #Dropserver apps and I look forward to converting one of my apps that doesn't need a relational DB from #sqlite to Deno kv.
#Deno key-value store now has an official page:
...and docs:
https://deno.com/manual@main/runtime/kv
My quick thoughts on what this means for #Dropserver apps:
I'm looking at config file formats for #Dropserver app metadata. #TOML looks good but there are criticisms I can't ignore:
https://hitchdev.com/strictyaml/why-not/toml/
I can't tell whether it's a case of people expecting too much out of a simple config, or "grass is greener on the other side"? or maybe "the only config file format nobody complains about is the one nobody uses".
More signifcant might be that TOML has very little mind share in the #JS universe so it might be DOA given apps are written in JS.
New: you can give #Dropserver a try using #Docker. Just run:
docker run -p 5050:5050 teleclimber/ds-host:latest
Then look at the logs for the setup link. More details here: https://dropserver.org/docs/ds-host-docker
Note this is meant for "kicking the tires" around the DS interface, not for running in production.
Unfortunately still missing is an easy way to get apps. App packaging and distribution is the next big thing I'm working on.
In the meantime, make your own apps? π
Interesting. It appears @denoland is implementing a key-value inside #Deno: https://github.com/denoland/deno/pull/18232
I had hoped they would implement #indexedDB, but this appears to be harder than it should be. https://github.com/denoland/deno/issues/1699#issuecomment-472237532
I would prefer a standard, but I'll take it.
In #dropserver apps I tend to import #SQLite as #WASM module, but that doubles the sandbox startup time. I can make do with a KV store if it comes for free. In many cases that will work well enough.
#wasm #sqlite #dropserver #indexeddb #deno
I've been playing around with #Docker to see if it would be a good way for people to install #Dropserver. Turns out, not so great.
- Running Bubblewrap within Docker is troublesome https://github.com/containers/bubblewrap/issues/505
- Create cgroups within the container is apparently not supported https://www.lewisgaul.co.uk/blog/coding/rough/2022/05/20/cgroups-questions/
Both are used to prevent a rogue app from ruining your day.
I'll probably still release a Docker image for local experimentation only. That will make it easier to et a taste of https://dropserver.org