Any chance that full GZIP support (for all databases and files), SPR: ARUI5Y9JPS, will make it to the final release?
(I think this is something that many people expect(ed) to find in 8.5)
Fredrik
Subject: What a list - hope you are right. - (missplaced,- this was ment as response to Eric)
Subject: It won’t be in 8.5
It does have a high priority for getting done soon after 8.5.
Subject: I would bet on Domino 9.0 for that one.
Domino 8.0 saw the last of the 16-bit memory handles removed (so I’m told).
Domino 8.5 is focusing heavily on NSF reliability.
Hopefully this combination is leading up to Domino 9.0 taking advantage of the pure 32-bit and 64-bit architecture, with:
-
Massive limit increases (16k/32k/64k field and summary limits gone for good)
-
True on-the-fly GZIP support
-
True DB-level JOINs (i.e. a DBLookup in a view column)
If we get those things then, oh my - what a backend!
Subject: I would not bet on this list Erik
I personally do not think the limits in DBLookup and others will ever change because of backwards compatibility … and you have the new javascript DBLookup in XPages so it will be interesting to see if they roll that back into core views (I wouldn’t vote for it)
Subject: Backwards compatibility should be easily addressable.
I don’t think IBM/Lotus would be terribly concerned with avoiding a limit increase, as ND6.0 allowed for @Formulas to work with >64K of data (though the results returned cannot be > 64K). There was no caveat given to backwards compatibility in this case, and I don’t think there needed to be.
But if there is an @Formula concern, all they need to do is create a new compiler symbol for the new version of @DbLookup, call it “@DbLookup”, and change the UI-representation of the old symbol to @V8DbLookup (or something similar).
This has already been done in the past with:
@V2If
@V3UserName
@V4UserAccess
I.E. when you opened up an R4 app that had been using @UserAccess in R5, all of your “@UserAccess” references suddenly started appearing as @V4UserAccess. No magic required!
It’s easy (or at least, well worth the tradeoff of finally being able to work with real, large amounts of data), keeps backwards compatibility intact, and doesn’t require any adjustment or touching of old dbs (i.e. no “convert” task or equivalent).