Keisuke, You are *the* man on character encoding stuff in 4D, so thanks for adding your observations.
I'm likely to be working with nothing but low ASCII, Latin1 data, for what it's worth. Just simple names for keys and numbers for most values. As far as the planning quesiton goes, I'm just trying to get some rules of thumb, not totally perfect numbers. And I think that I have that now: * 4D stores objects/text in UTF-16. * The data is stored in a binary format. * The binary format isn't really meaningfully more compact than the original text. (In fact, it may be larger for some reason.) That's enough for planning, if correct. And, for the application part: * An object field can be searched in various ways, so long as you use 4D's supported styles. * These styles of JSON are not (meant to be) space efficient. * If you want to do space-efficient, valid JSON, I don't think 4D offers any options. Nor does its parser. You need NTK to do very compact, valid JSON. I haven't used 4D's object fields much (obviously), but I've done a ton with JSON with various formats at scale. I've had to rework formats repeatedly in the past to address space and performance constraints. This is one reason I'd like a more complete JSON parser and code set natively in 4D. NTK is great, but not everyone has it and, in my experience, it's significantly slower than 4D's native JSON tools. (They're remarkably fast.) ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
