In-memory objects add complexity to the codebase and are not strictly needed for the dockerized dashboard

[felipesanches]

We do have special cases and additional code for handling file-like in-memory objects. This code was created when we first drafted the drag-n-drop webapp that is hosted on Google App Engine, because server-side filesystem operations were forbidden and also because certain tools were not available on GAE.

These restrictions do not apply to Gooogle Container Engine. Thus, I believe that we would greatly benefit in terms of codebase simplification and clarity, by completely ditching that feature. As the current drag-n-drop implementation is planned to be deprecated by substituting it with a docker-based solution as well, we'll soon be able to save whatever the user uploads on a temporary folder in the container and then simply do the job without the fancy data-juggling we currently do for GAE.

[felipesanches]

This is directly related to issue #1230

[davelab6]

I don't think this is too important, and I would like you to consider and test for the possibility of going back to disk based access will slow things down a lot :)

…

On Apr 8, 2017 7:09 AM, "Felipe Corrêa da Silva Sanches" < ***@***.***> wrote: This is directly related to issue #1230 <#1230> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1274 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAP9y06gmwPYMNib9J4hd2Qyi-NM3h2fks5rtxZ_gaJpZM4M3mMg> .

[felipesanches]

In my opinion it is important, even though it is not top-priority indeed.

Slowdown from disk I/O is only critical when we're performing a whole bunch of tasks in automated/bulk fashion, because the tiny extra delays add-up. For users on-demand upload of files on a low-volume webapp (such as this drag-n-drop solution), the performance hit is negligible. The user's mouse-clicks are probably slower than the disk I/O operations.

And also for the batch-jobs (which would suffer more significantly from disk-I/O latency), we're already having to resort anyway to saving the files to disk when performing git clone operations on the font project repos...

[felipesanches]

Having said that, the benefit of less cruft on the codebase is much more significant then any perceivable performance hit of disk I/O for the handful of font files a user may upload at once when using the drag-n-drop fontbakery checker interface.