Jim
Yes you're right that whatever cut-off point you use for string length
handling will never be enough and conversely you could therefore
theoretically downsize to accommodate any small string length. The
point is that EWD has been designed around the original Cache 32k
limit and has been tested to death in real world commercial web
application development situations for 6 or more years and is known to
cope with anything that's been thrown at it to date. I've made it
available to the marketplace as a free open source product knowing
that I'm unlikely to see any immediate commercial return for doing so
and therefore I have pretty much zero incentive to spend any of my
otherwise busy time fixing something that ain't broke and I certainly
don't have any motivation to do anything to EWD that would
unecessarily risk destabilizing it in the short term.
Let's be clear: getting EWD to work with GT.M and VistA is not
difficult or rocket science - either configure a 32k database for its
specific use, or configure the entire environment to work with 32k
strings. I'm not sure I understand the resistance to doing this or
the apparent inability being demonstrated to make this happen.
Can I ask the question: 9 months after having one out of my way to
make it available as Free Open Source to try to provide this community
with a state of the art tool for Ajax development, is *anyone*
actually using EWD with VistA yet? I have to be honest and say that I
do wonder sometimes why I bothered. All I seem to hear is reasons why
people haven't used it or don't use it.
On 4 Sep, 20:01, Jim Self <jas...@dcn.davis.ca.us> wrote:
> rtweed wrote:
> > Jim
> > You have to understand that (like most software that I anticipate
> > ending up in GT.M over coming years) EWD was originally developed on
> > Cache where 32k strings are the norm. Much of EWD's compiler
> > functionality has been designed and relies on the fact that 32k
> > strings are available in global storage. I dare say I could mess
> > about and re-code stuff to make do with a lot less, but
> > a) I don't have the time (or rather can't justify it),
> > b) I don't want to risk de-stabilising EWD unecessarily and
> I was hoping that the 32KB assumption was not scattered all over the EWD
> code. If not, direct global gets and sets for very long strings might be
> easily replaced with a pair of function calls.
> > c) 32k string handling seems entirely reasonable in this day
> I agree, but even 32KB, or 64KB, or 128KB, etc. is not large enough to
> handle all the strings one might need to store. GT.M allows 1MB strings
> in local variables and functions. What happens when a string exceeds the
> 32KB limit? Do you prohibit that or crash or resort to chunking then?
> Back in the bad old days following the demise of Datatree, Micronetics,
> and the MUMPS User Group and before GT.M was Free (Open Source), we
> implemented M-globals for PERL on the B-tree module of BerkeleyDB.
> BerkeleyDB offered 8-bit clean associative array keys and data values of
> unlimited length but its performance was not in the same class as any of
> the existing MUMPS implementations.
