~sircmpwn

Philadelphia, PA

https://drewdevault.com

I write code.

For sourcehut support, see the wiki.

Trackers

~sircmpwn/gmni

Last active 13 hours ago

~sircmpwn/builds.sr.ht

Last active a day ago

~sircmpwn/scdoc

Last active a day ago

~sircmpwn/aerc2

Last active 2 days ago

~sircmpwn/meta.sr.ht

Last active 2 days ago

~sircmpwn/man.sr.ht

Last active 4 days ago

~sircmpwn/sr.ht

Last active 13 days ago

~sircmpwn/hub.sr.ht

Last active 13 days ago

~sircmpwn/todo.sr.ht

Last active 15 days ago

~sircmpwn/dowork

Last active 16 days ago
View more

#130 Rig up button to remove attachments 7 hours ago

Ticket created by ~sircmpwn on ~migadu/alps

#118 (Optional) JavaScript-driven attachment upload interface 7 hours ago

Comment by ~sircmpwn on ~migadu/alps

It would probably be easier and lighter weight to just build something bespoke, a JavaScript drag and drop file uploader thingy would clock in at <100 lines of code.

Got it in 146.

Filed follow-up tickets for future work: #128, #129

REPORTED RESOLVED IMPLEMENTED

#129 Gracefully handle server-side errors in the attachment interface 7 hours ago

Ticket created by ~sircmpwn on ~migadu/alps

#128 Add upper limit to total attachment size which can set on a user session 7 hours ago

Ticket created by ~sircmpwn on ~migadu/alps

If the user attempts to upload too many attachments at once, we'll error out and offer a button to clean out the unsent attachments first?

#118 (Optional) JavaScript-driven attachment upload interface 11 hours ago

Comment by ~sircmpwn on ~migadu/alps

Returning to the inbox while processing uploads in the background would be a very intrusive change. It would basically require turning the entire application into an SPA, or some kind of faux-SPA at the least.

The approach I'm working on now (we'll see if it's any good) starts uploading the files as soon as you add them to the file box (or drag and drop them) and shows a little progress bar and such. It'll prevent the user from sending the message until all uploads are completed. It falls back to the same behavior we had before if JS is disabled.

Let's see how this approach feels before trying something which requires a broader overhaul to the application.

#18 Switch to some other TLS implementation 13 hours ago

Comment by ~sircmpwn on ~sircmpwn/gmni

I would be interested in at least seeing what a BearSSL-based implementation looks like.

#44 gmnisrv: pollfd realloc or client disconnection invalidates past pollfd pointers 23 hours ago

Comment by ~sircmpwn on ~sircmpwn/gmni

Hm, a more robust solution would probably be to store the index in the client and set the fd to -1 in the pollfd to indicate that it's available.

#1 Extract client into a standalone library a day ago

on ~sircmpwn/gmni

REPORTED RESOLVED FIXED

#24 gmnisrv: address slowloris attacks a day ago

on ~sircmpwn/gmni

REPORTED RESOLVED FIXED

#29 gmnisrv: test under simulated poor network conditions a day ago

on ~sircmpwn/gmni

REPORTED RESOLVED FIXED