Byte limit for post text is too small.
Phil Pilgrim (PhiPi)
Posts: 23,514
I was experimenting with my public "post fixing" website (linked to here) to repair one of my posts that got clobbered in the migration. In the process, I bumped into a 10Kbyte limit on the size of the post contents and could not repost the repaired text. 10K is way too small. A limit of 64K or 128K would be much more reasonable.
-Phil
-Phil
Comments
It is also quite possible that some of the attachments have file extensions that are not configured in the new site. We started with a list of over 200 extension types and narrowed it down to about 60. This resulted in coverage for 93% of the attachments.
I can make adjustments to the upload size settings as soon as we can identify exactly what file types are not working.
The 10K was not a limit on attachments but on the actual text that goes into the post itself.
-Phil
I just increased this 50K. We can go higher but I need to keep a maximum to ensure that someone doesn't try to post a copy of War and Peace online.
-Phil
Hi Jim Ewald
As I can see in Manage attachments most of file types used on Propeller part of forum have to small sizes.
spin = 97.7KB --> need 300KB
(As we now have PBASIC we need 2 more extension)
pbas = xx.x --> need at last 100KB
lib = xx.x --> need at last 100KB
To that file extensions for C and Java
(pixel limits Bigest PC scren resolution as many of us use scren capture to make them)
jpg = 97.7KB --> need 1MBB (All 3 types are same - only difference is OS that generated them)
jpeg = 19.5KB --> need 1MBB
jpe = 19.5KB --> need 1MBB
(You need both extensions -> You have only tiff)
tiff = 97.7KB --> need 1MBB
tif = xx.xKB --> need 1MBB
png = 97.7KB --> need 1MBB
(Mostly used for animations pixel rate is ok but need at last -> 1MB to have acceptable time length sequence)
gif = 19.5KB --> need 1MBB
txt = 97.7KB --> need at last 200KB
doc = 19.4KB --> need 1MB (Maybe more as Doc's with embedded graphics can be very BIG)
zip = 976.6 -> Is ok
pdf = 2.8MB -> Some pdf's can be biger
I can't talk on extensions that needs on other threads.
Thanks for the detailed information. I added the new extensions and updated the current definitions. The image size has been increased to 800 x 600 for most image types. I'll get the rest of them shortly.
I have some reservation with increasing the cap on .doc files. My thought is that anything larger than 2 - 3 MB should probably be placed in a ZIP file. Over 70% of what we're storing in the database now are attachments and images. I would like to see that go lower in the future.
Hi Jim Ewald
THANKS
I think 1.91MB is OK for "doc" and as You said - biger cna be in zip/rar
You need look on BMP extension to to have at last 500KB (Normaly as them are not scrambled Them are biggest of all PIC types
pbas, lib can need be little bigger -> BUT that can BEAN answer
Have one Question to You?
It is possible to have small PIC's side of uploaded file names for PIC's that show what are on that picture?
-Phil
I'm asking because the work product of this kind of community discussion is strongly associated with attachments and images.
That is where a very significant part of the value is, and I for one would be happy to contribute to some storage, if that's at issue.
Different communities have different products. If it's politics, for example, the majority will be links and text, as the writing is the primary value, as is commenting. Those kinds of communities tend to maintain more meta-data, than this one does, FYI.
There is a top-notch gaming community (retro gaming) that I participate in. There, images, captures and attachments are highly valued as well. A very interesting meta-discussion happened a year or two ago. The size of the site was discussed as well as the value. The admin / owner took a while to do some analysis and was shocked at the number of outside links, conversation, and other valuable information being referenced by and associated with those things.
(their solution was to limit deep linking in some cases, because throughput charges were at issue there)
That community is probably an order of magnitude larger in scale than this one, and it's privately run for pleasure. A simple bit of throttling on this one would prevent that from being at issue, without significant, if even noticeable impact.
A CAD discussion group I frequent, often has fairly large attachments, and or needs the use of a file drop. (that one is kind of outta control, IMHO)
Here, the context is mixed. The text for an entire day of discussion is probably equal to one or two average images, or program code files. Honestly, the robustness of communication permitted here to date, is one of the reasons the venue thrives as it has, and I think that's very important to consider.
My own experience with managed data in the engineering CAD work-group context has shown that storage has always continued to exhibit lower costs over time, despite fairly aggressive work product per week numbers. That's not always true for network throughput however, and is something to be balanced, but I have to ask whether a speed limit isn't a fair trade for robust communication, in this particular context.
my .02
It's also a key savings on overall bits transferred, which is generally why thumbnails are so pervasive.
I agree with Potatohead. Disk storage is extremely cheep these days. The attachments are an important part of the tool. It seems to me, the more we encourage attachments, the clearer our communications.
Sorry if I'm troublesome BUT as I always say "It is not computer that shall control me, It me that shall control Computer"
I dont think as pixel size limits on attachment's are GOOD idea it is only file size that need limits.
ON in line PIC's - THAT is ok to have pixel size limits.
-Phil
Generic storage is cheap these days. High-end, fault tolerant, hi-bandwidth, networkable storage is considerably more expensive.
Most of that stuff is oversold.
I think sometimes the scale of things gets distorted.
For something like this, those higher end things really are not necessary. And they only become necessary when either the complexity of the data compute required to communicate, or the pipe containing requests grow to a very high level; otherwise, it's all sharply throughput limited, meaning there are a lot of moderate scale choices that are perfectly viable, possible and practical.
As the scale of the organization, and it's data needs moves up into mid to large business, that stuff changes, and the expensive gear is worth it. No question on that.
And storage featuring some or all of those attributes has always come at a premium. The key is knowing whether or not there is actually a return on that. One element is buy or build? On one hand, buying into a supported system means not having to do some work, and take some risk. Building one is just a different sort of work, and a different risk.
Where those expensive systems are actually indicated (and that's not as often as those vendors would have you believe), the premium pays in a matter of months. No brainer. At that scale, storage is still "cheap" and growing "cheaper", as it always has.
The bottom line on storage is the only real "expensive" storage, regardless of scale, is that storage where the requirements indicate early adoption.
Most all use cases right now are well served by the majority, and often late majority tech, which is time tested, cheap, robust, and common.
Can anyone of You remove Pixel rate restrictions from >ATTACHMENTS.
As it is now it is not unusable at all. We have already restrictions on ATTACHMENT file size restrictions ad it is OK.
BUT pixel rate restrictions resize attachments to be out of use.