On Sun, Oct 21, 2012 at 10:09 AM, Jeremy Nicoll - ml sourceforge <
jn.ml.sfrg...@letterboxes.org> wrote:
> Mark Miesfeld <miesf...@gmail.com> wrote:
>
> > Yesterday when I said that adding encryption did not change the database
> > size by much, I was wrong.
>
> Do you mean /binaries/ size?
>
Yes, I did mean the size of the ooSQLite binaries there. The 2 files:
oosqlite.dll and ooSQLite3.exe
>
>
> >Right now I'm thinking of having one ooSQLite.cls file with the key and
> >rekey methods, a method for checking if the loaded DLL has encryption
> >support or not, and adding encryption support enabled / disabled to the
> >output of the version command. If the DLL without encryption support is
> >loaded, then key and rekey return an error code if invoked.
>
> Can one also test the DLL version from rexx easily?
>
Not sure if I know what you mean by the DLL version here. If you mean, is
the DLL the version with encryption enabled, then in Rexx it would be
something like
db = .ooSQLiteConnection~new("myTest.db")
if .ooSQLite~hasEncryption then do
-- ret should be a good return code
ret = db~key('123ABC')
end
else do
-- ret will be MISUSE
ret = db~key('123ABC')
end
If you mean the actual build version of the DLL, then that is already there
.ooSQLite~version('C') will return something like: 1.0.0.8519
,ooSQLite~version('O') will return something like: ooSQLite Version
1.0.0.8519 (64 bit)
The 8519 gives the exact svn revision number of the source code used to
build the DLL
If it is decided to produce a DLL with encryption compiled in, I will
probably add to the second version string something like:
ooSQLite Version 1.0.0.8519 (64 bit) (Encryption enabled)
ooSQLite Version 1.0.0.8519 (64 bit) (Encryption disabled)
along with the method hasEncryption()
>
> >There are other ways to do this of course. There could be two completely
> >separate packages with different file names. Or there could only be the
> >DLL with encryption support.
> >
> >Wonder what people think here.
>
> I wonder how one would set up multiple versions of the DLL for, say,
> migration testing of a live app from one level of SQLite to another.
> Provided there's an easy way to handle that, I doubt it matters much.
>
>
There is the same way we discussed before. Put the different DLL files /
.cls files in separate directories and run each one from a separate command
prompt session with different PATH variables. The PATH points to one
location in one session and in the other session the PATH points to the
second location.
> The drawback of multiple packages with different names is it could be the
> thin end of a wedge... leading to many packages one day all offering
> slightly different things.
>
Yeah, I'm not interested in inserting that wedge.
One of the advertised benefits of SQLite is its small binary file size. To
me the difference between an oosqlite.dll of 1,913,344 bytes and one of 790,016
bytes is insignificant. But, I know of some people in the Rexx community
that would aghast at that statement, how could I conceivably think a 220%
size increase was insignificant.
And it would be simpler to just provide one ooSQLite package that
had encryption enabled. Anyone that didn't want to use encryption wouldn't
have to by just not coding any db~key(x) or db~rekey(x) statements in their
code. There would be no penalty for that person, except a bigger
oosqlite.dll file size.
--
Mark Miesfeld
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
