Re: [vwnc] Managing Large File Uploads in Seaside

Overrides are a door to abuse and sometimes an indicator or a bad design,
IMO, but as with other powerful tool, it depends on each case.

What I don't like the pragma based configuration of this part, the whole
senders/implementors and class references of Smalltalk are not of much use
there, since it is hard to find where things are defined, configured, etc.

E.g. SeasideResponder class>>#configureCurrent

Regards,

Esteban A. Maringolo


On Wed, May 8, 2019 at 2:54 PM Tom Robinson <[email protected]> wrote:

> Hi Karsten,
>
> This appears to be a common issue. As such, rather than just using an
> override, maybe Cincom should be asked for an implementation change that
> would ALLOW subclasses to customize this without too much code duplication.
> In my opinion, if an override is needed, in most cases it indicates that
> more flexibility in the original implementation is needed.
>
> Tom
>
> On 5/8/2019 11:30 AM, Karsten Kusche wrote:
>
> What do you mean by body size limit? Is that a http thing?
>
> As for subclassing, the method in question isn’t written in a way that
> would allow subclasses to customize something without copying too much
> code. In that case an override is better, because there’s tool support to
> find overrides and inspect them upon migration.
>
> Karsten
>
>
>
>
> Am 8. Mai 2019 um 19:23:15 MESZ schrieb Esteban Maringolo
> <[email protected]> <[email protected]>:
>
> Hi Karsten,
>
> I didn't think about an override and went subclassing directly (I'm not
> keen/not used to method overrides), but your approach of having a threshold
> seems like a good tradeoff to preserve the simplicity for small files.
>
> What I couldn't find is whether the maximum request body size is enforced
> with Seaside (I placed a few breakpoints around senders of
> #requestBodyLimit without any luck).
>
> Regards,
>
> Esteban A. Maringolo
>
>
> On Wed, May 8, 2019 at 1:59 PM Karsten Kusche <[email protected]> wrote:
>
> Hi Esteban,
>
> we have an override in SeasideResponder>>asSeasideFileStream: where we do
> something differently in „stream isExternalStream ifTrue:[…]“
>
> There we ask the stream for #fileName (returns a Filename object) and test
> the file size. That’s the file that contains the data that was uploaded. If
> the file’s size exceeds a certain threshold we return a subclass of WAFile
> that knows the file and not its contents.
>
> Kind Regards
> Karsten
>
> Georg Heeg eK
>
> Wallstraße 22
>
> 06366 Köthen
>
>
>
> Tel.: 03496/214328
>
> FAX: 03496/214712
>
> Amtsgericht Dortmund HRA 12812
>
>
> Am 8. Mai 2019 um 16:29:29, Esteban Maringolo ([email protected])
> schrieb:
>
> I found that SiouX is effectively uploading the contents to an attachment
> file directory.
>
> Maybe there is a way to avoid instantiating a WAFile and use a
> WAExternalFile poiting to the file on disk, or simply using my custom
> SeasideResponder subclass.
>
> This won't save VW from reading the whole file into memory before saving
> it to disk (or will it?) but it certainly will only keep the reference
> during the request/response of SiouX, which will be garbage collected
> faster than anything on a Seaside Component.
>
> Regards,
>
> Esteban A. Maringolo
>
>
> On Wed, May 8, 2019 at 10:10 AM Esteban Maringolo <[email protected]>
> wrote:
>
> Hi Felix,
>
> That is similar to what Johan proposes in his article, but the goal is to
> achieve the same thing by using SiouX (VW's latest HTTP server) responders,
> maybe using a chunked read/write approach (so there is no more than a
> certain buffer in the object memory).
>
> Regards,
>
> Esteban A. Maringolo
>
>
> On Wed, May 8, 2019 at 9:46 AM Félix Madrid <[email protected]> wrote:
>
> Hi Esteban,
>
> Maybe this article (and project) from Nick Ager can help you:
>
> http://nickager.com/blog/2011/07/01/File-upload-using-Nginx-and-Seaside
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__nickager.com_blog_2011_07_01_File-2Dupload-2Dusing-2DNginx-2Dand-2DSeaside&d=DwMGaQ&c=OCIEmEwdEq_aNlsP4fF3gFqSN-E3mlr2t9JcDdfOZag&r=dvjp1HPIw2veDqoXGboS25_BQZgS48rpxicfFO4TU2Q&m=ONky_HujutcG36aWWzrUjY_6ahacPyYsjpo6Eh2OWzE&s=8CLW_694Cyyfynuhkv78YvThaum8a0bjQgvr5Vp6qEA&e=>
>
> Cheers,
>
> Félix
>
> On Wed, May 8, 2019 at 2:39 PM Esteban Maringolo <[email protected]>
> wrote:
>
> I'm trying to use the SiouX responder fortification to limit a large file
> upload from blocking the whole image and/or filling its memory.
>
> Looking at the options I found there is a "save attachments as files",
> which seems like a similar approach as the one proposed at <
> https://jbrichau.github.io/blog/large-file-upload-in-seaside
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jbrichau.github.io_blog_large-2Dfile-2Dupload-2Din-2Dseaside&d=DwMGaQ&c=OCIEmEwdEq_aNlsP4fF3gFqSN-E3mlr2t9JcDdfOZag&r=dvjp1HPIw2veDqoXGboS25_BQZgS48rpxicfFO4TU2Q&m=ONky_HujutcG36aWWzrUjY_6ahacPyYsjpo6Eh2OWzE&s=62wmHVN59u1Z0_tP2CcYdpULLFAPtfQxL8OupcfF8dA&e=> >
> using NGINX or Apache, but apparently that option only works at
> NetHttpResponder, but it's not applied in Seaside.
>
> Did anybody integrate this feature or a similar one with Seaside in VW?
> (otherwise I'd have to do it myself).
>
> Regards!
>
> Esteban A. Maringolo
>
>
> _______________________________________________
> seaside mailing list
> [email protected]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.squeakfoundation.org_cgi-2Dbin_mailman_listinfo_seaside&d=DwMGaQ&c=OCIEmEwdEq_aNlsP4fF3gFqSN-E3mlr2t9JcDdfOZag&r=dvjp1HPIw2veDqoXGboS25_BQZgS48rpxicfFO4TU2Q&m=ONky_HujutcG36aWWzrUjY_6ahacPyYsjpo6Eh2OWzE&s=nHlYojUD1UOoH_oDklxP36VzZwCUmqixZ28E7uSyI_E&e=>
>
>
>

_______________________________________________
seaside mailing list
[email protected]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside