vibe.d: How to get the conent of a file upload ?

[wjoe]

On Friday, 18 September 2020 at 22:02:07 UTC, aberba wrote:
>> [...]
>
> That's what I was trying to answer. When Steve said meh, he 
> probably didn't get what I said. Probably its because of my 
> typos.
>
> This sort of convenience and productivity benefit is part of 
> why I use Node.Js in the job when I need to get things 
> done....and not D yet. There are several pieces and bits you 
> can't write yourself when working on projects.
>
> In this case you want to get the file(s) in memory...in the 
> form of bytes (or buffer) and probably set a file size limit. 
> Its all doable through a library but such a library doesn't 
> exist in D yet. At least not that I know of.
>

Yes it would be convenient and thanks for the links but since I'm 
not familiar with Node.js at all parsing the input myself will be 
better than getting into Node.


> Vibe.d still lacks many things I personally need... there's 
> simply not enough ecosystem third-party libraries.

My first impression of vibe.d is that the author(s) made a 
presumptions about the one way things should be done(tm) and if 
that's not your use case too bad for you.
That's where most of my displeasure of using vibe.d comes from 
and that those aren't described in the documentation - not so 
much because of the things that aren't implemented (yet).

Handling file uploads is one example, another is command line 
arguments.
The presumption here is there is vibe and there can only be vibe. 
It takes them from Runtime.args. Duh?
This didn't make sense to me until I saw example where the 
initialization of vibe was done in a module constructor.
Looks cool on a cursory look but is incredibly impractical if you 
don't want to do it that way. And that's the gist - vibe.d is 
incredibly impractical if your use case doesn't exactly match the 
author(s) assumptions of the one way to do things(tm).
And there are issues with that, too. E.g. in the example the 
server will be started before command line args are completely 
processed. That means if there are wrong or missing or extra args 
the application aborts and leaks OS resources.
The way I would have implemented it is to take args from 
Runtime.args by default but allow passing an args[] to a vibe 
args-handler. I could then parse whatever args I'm interested in 
in my favorite way and pass the rest to vibe.

But you can handle those with vibe getOption or some such - why 
don't you want to do comandline args processing with vibe you ask 
?
Because 1. there's std.getopt which is awesome, and
2. If I don't depend on vibe to parse them and I have a build 
configuration with version="NO_SERVER" I don't even need to link 
against vibe and its dependencies.

By using vibe I feel like I need to bend myself like a snake and 
jump through the hoops of vibe's one way to do it. You save a lot 
of time here and there and then you lose half a day because of 
some stupid road block like the above.