Tickets :: Comment on [#2315] Provide VFS db drivers that spool blobs using streams

* Your Email Address
* Spam protection	Enter the letters below: . . __ .__.. ..__. \| \|/ `[__]\| \|\| \| \|/\\|\__.\| \|\|__\|\|__\
Comment	> === OFF TOPIC, JUMP DOWN IF NOT INTERESTED === > > > >> I really am not sure what I said to set you off so much. I was not > >> trying to be condescending, and I am sorry you took it that way. > > > > Let me explain by rephrasing and condensing your initial reply. I > submitted a bug and you said approximately the following: "Even > though I haven't tested it, I don't think this bug is real. And you > haven't done your homework because it's in plain sight in the mailing > list archives and in the bug index, but I haven't taken the time to > verify that claim. Please don't bother us again, we're busy." Don't > you understand now? > > > > Let me take this further and explain to you how you should have > replied, so that you may learn from this experience. (Side note: > Yeah, I am being condescending on purpose, but in a sarcastic way.) > > > > First, before any reply, if you think this bug has been discussed > before you absolutely need to search for the URL. If you can't be > bothered to do that you just can't reply telling me that this bug has > already been discussed. That would be considered rude. Let other > people search for yourself instead and see the bug closed without > your intervention. If you think it is so evident that the bug has > already been discussed, it is so much in plain sight, it shouldn't be > hard for you to find a URL. Taking the time to find the URL also has > the advantage of preventing you from being wrong, as you were with > me. When you give a URL you have proof of your claim: the bug really > has been discussed before. > > > > Assuming you have determined that the bug hasn't been discussed > before, the second step is, still before any reply, trying to > reproduce that bug, assuming you have any interest in fixing it. If > you don't have any interest in fixing it then you can just ignore the > bug, other people will try. If you can't reproduce it, you reply > something along the lines of "Couldn't reproduce. Test setup: mysql > X.Y.Z, IMP 3.X, Apache X.", you set the state to feedback and you > wait for more info. If you can reproduce it, then you may confirm the > bug. Assuming you still are interested in fixing it, you may proceed > to actually fixing it. > > > > Through all these steps, if you are not interested in fixing the bug, > just leave it alone. Other people will be interested. > > > >> As far as providing a URL where you could find information - > >> unfortunately, I am not a paid support agent of Horde. I would > >> really love to help everyone, and if I had a URL close at hand I > >> would have given it. Instead I suggested a place you could search. > > > > And by doing this you took a risk: maybe you were wrong, and such a > URL didn't exist. And this time, you were indeed wrong. Another > guideline: don't suggest places where one can search. That's > condescending. It's exactly as if I explained to you the initial > steps in the bug fixing process (oops, I already did that it seems). > > > > === BACK TO ON TOPIC STUFF === > > > >> First of all, internet mail is > >> not the place to be sending around 10 MB files but this religious > >> argument has already taken place on the mailing lists and I will not > >> address it anymore here. > > > > That's not the point, but I agree: let's not be religious. > > > >> Second, I can send 10 MB files without PHP > >> using anywhere near 320 MB of memory so it is clearly not > >> reproducible for everyone. > > > > AH! New information! Thanks for finally trying to reproduce the bug. > Can you elaborate on what versions were used in your test setup? Were > you using the VFS for storing attachments? Let's try to isolate the > bug. > > > >> Third, this is a PHP issue as much as > >> you don't believe it is. > > > > I think you misunderstand what this bug is about. This is not about > "I can't send attachments of size N or bigger". It is about "I can't > send attachments of the size IMP has been configured to accept". If I > set the maximum to 10M, I can send attachments up to about 1M. If I > set the maximum to 2M, it's about 500K. As I go smaller, the maximum > size goes smaller too. But the actual limit is never equal to what > IMP has been setup to accept. That's the problem. > > > > Analogy: the speedometer on my car tells me I'm going at 100 km/h but > I'm really at 50. Then I go down to 50, it tells me I'm at 25. That's > a calibration problem, and it's the same kind of problem that this > bug is about.
Attachment
Watch this ticket

Saved Queries