From: *Mark Rotteveel* m...@lawinegevaar.nl mailto:m...@lawinegevaar.nl
Date: Sun, May 26, 2013 at 11:53 AM
Subject: [Firebird-devel] RC4 for encryption?
To: For discussion among Firebird Developers
firebird-devel@lists.sourceforge.net
mailto:firebird-devel@lists.sourceforge.net
If I
On 5/27/2013 3:53 AM, Mark Rotteveel wrote:
On Sun, 26 May 2013 13:36:36 -0400, Jim Starkey j...@jimstarkey.net
wrote:
Read the fine print. To break a message, you need 2^30 encrypted
versions of a message containing a 256 byte constant block starting at a
fixed position. Nice theoretical
encryption plugin - if you really do
not trust it you can easily write your own.
On 05/26/13 21:36, Jim Starkey wrote:
I don't know what Firebird is now using for password validation, but I
strongly suggest that somebody look closely at SRP (secure remote
password) to generate session keys
60% the length of Firebird's run length encoding.
XDR is getting rather long in tooth, don't you think?
On 5/28/2013 6:54 AM, Alex Peshkoff wrote:
On 05/27/13 20:10, Jim Starkey wrote:
Is the attach package encrypted with the session key? If so, the hash
of the session key isn't necessary
Guys, it was close to 30 years ago, but my best guess was that it would tell
the AST that the event was cancelled so it probably wouldn't be a good idea to
requeue the events. It eliminates a potentially nasty race condition when
events are posted while another thread is trying to cancel.
Sorry about the long delay, but we were way down east in Maine.
An essential flaw that Firebird inherited from Interbase is the way
system tables are initialized at server startup. The current scheme
makes it extremely difficult to make changes to the system tables
without declaring a new
OK, here's another humble suggestion that folks might want to consider
for a future version: Support an upgrade object syntactically
parallel to create object. The upgrade version, however, takes
the existing object, compares it to the described object, and makes any
changes necessary. If
:46 AM, Ann Harrison wrote:
On Aug 31, 2013, at 4:55 AM, Mark Rotteveel m...@lawinegevaar.nl wrote:
On 29-8-2013 17:41, Jim Starkey wrote:
Paradoxically, Japanese strings tend to be shorter in UTF-8 than 16 bit
Unicode. The reason is simple: There are enough single byte characters
On 9/3/2013 8:02 AM, Alex Peshkoff wrote:
On 09/03/13 13:21, Dmitry Yemanov wrote:
03.09.2013 11:13, Alex Peshkoff wrote:
That's definitely a candidate for next ODS. But I see one problem -
currently all (or at least most of all) record buffers are allocated at
prepare time. With variable
Unbounded types work very badly with the SQLDA. The original SQLDA was
lifted verbatim from the DB2 spec, circa 1985, because I wanted
something more or less standard. It was pretty much awful then and it
hasn't gotten much prettier since. On the other hand, it's what
everything uses for
A clob is nothing but a blob that is thought to be character.
On 9/4/2013 6:40 AM, Adriano dos Santos Fernandes wrote:
On 04/09/2013 05:09, Alex Peshkoff wrote:
On 09/04/13 11:53, Dmitry Yemanov wrote:
04.09.2013 11:43, Alex Peshkoff wrote:
May be in that case next step? Keep declaring
On 9/5/2013 4:28 AM, Alex Peshkoff wrote:
On 09/04/13 18:11, Jim Starkey wrote:
So here's another seriously heretical thought. If you're planning for
Firebird to hang around another 27 years, it's time to define a modern
OO API that is easy to use from modern languages, is flexible
A couple of folks asked, so here it is.
The scheme centers around pattern strings. A pattern string represents
one of any number of possible interpretations of a target string. A
pattern string consists of punctuation characters and the characters A
and 9 representing consecutive sequences
On 11/1/2013 6:49 AM, Alex Peshkoff wrote:
On 10/29/13 20:01, Dimitry Sibiryakov wrote:
Hello, All.
Did someone try to cut subj off and feed metadata from system tables
directly every
time when they are needed?
May be Jim? About 25 or more years ago :)
NFW. That's crazy. All
Jaybird? Now that is confusing. Jaybird was the DEC internal code name
for what became Rdb/ELN, the immediate precursor to what became Interbase.
On 8/4/2013 8:39 AM, Mark Rotteveel wrote:
Has anything changed in Firebird 3.0 with the stability of RDB$DB_KEY or
how RDB$DB_KEY works?
Jaybird
On 11/13/2013 4:01 AM, Dimitry Sibiryakov wrote:
13.11.2013 9:17, Alex wrote:
For me main problem is that we do not know format of interbase messages
when boolean is used in them. We do not know alignment rules. We know
_nothing_ about internals of boolean implementation in interbase.
On 11/13/2013 10:55 AM, Dimitry Sibiryakov wrote:
13.11.2013 16:50, Jim Starkey wrote:
OK, I give up. How can there be different UTF-8 character sets when
UTF-8 is defined by inter-galactic standard?
Our utf-8 charset has different id than IB's, so if someone use
XSQLVAR.sqlsubtype
On 12/3/2013 6:24 AM, Mark Rotteveel wrote:
On Tue, 03 Dec 2013 12:10:30 +0100, liviusliv...@poczta.onet.pl
liviusliv...@poczta.onet.pl wrote:
Hi,
Will be good to have some configurable option for data type result for
count(*).
In FB3 result rype is bigint in previous it was integer.
All
On 12/3/2013 12:31 PM, Dimitry Sibiryakov wrote:
03.12.2013 18:25, Dmitry Yemanov wrote:
Doesn't it mean that such an application will be always passing SQL_LONG
to execute/fetch calls?
No, it is much more stupid. Application get ISC_INT64 from API, derive
fields type
fbBigint from it,
For what it's worth, gpre was my very first C program in 1984. It was
written on a 16 bit Unix running on a DEC Pro/350 (a pdp-11). It's
coming up on its 30th birthday next September, so be kind to it. It's
probably among the oldest pieces of working software on the planet.
On 12/5/2013
On 1/2/2014 8:10 AM, Simonov Denis wrote:
Dmitry Yemanov firebi...@yandex.ru писал(а) в своём письме Thu, 02 Jan
2014 15:55:57 +0400:
This makes it necessary to allow the FIRST ROWS mode when it's needed.
I'm proposing the following:
1) FIRST ROWS mode is implicitly used when the FIRST /
On 1/7/2014 1:14 PM, Simonov Denis wrote:
Why it have to have fixed position? Cannot btyacc syntax parser handle a
clause anywhere?..
Course parser can parse and tips from various places, but I look at it
from the perspective of the application developer. It is much easier to
remove or
Does Firebird use cmake? If so, cmake has a find_package mechanism
that is platform, compiler, and version independent. If Firebird
doesn't use cmake, well, it should.
I haven't looked at this, but there is a package definition at
https://github.com/julp/FindICU.cmake.
On 2/14/2014 11:57
Would it be feasible to restructure ICU has a master DLL/shared image
plus a DLL/shared image per character set loaded on demand? If so,
Firebird could be packaged with a small subset containing popular
languages with others available for download somewhere.
On 2/19/2014 10:30 AM, Paul
On 3/6/2014 10:39 AM, Alex Peshkoff wrote:
On 03/06/14 19:30, Dimitry Sibiryakov wrote:
06.03.2014 16:21, Alex Peshkoff wrote:
BTW, when using new interface message about bad SQLDA looks silly.
Who has an idea what to do with it?
Replace them with complaints about BLR.
Also far from
Ann and I know Peter and his wife Trudy very well. For most of the time
we were there, Trudy was the other woman in engineering. Peter is much
more of a theoretician than a developer, so he may not be fully up to
speed on the practical implications of some of this stuff.
The MySQL
On 3/18/2014 7:47 AM, Alex wrote:
On 03/18/2014 01:26 PM, Dimitry Sibiryakov wrote:
Back to the question:
17.03.2014 12:30, Alex Peshkoff wrote:
Besides, storing reference to object already increment its
usage counter, so nobody can free the object during wrapper's life time.
But
User updateable system tables seemed like a good way to build a access
language neutral database engine for Rdb/ELN and Interbase. The Rdb/VMS
guys never warmed to the concept, and developed an MBLR (metadata BLR)
mechanism. It wasn't a big hit, either, and I eventually created DYN
for many
I was thinking about your mutex protected linked list when it occurred
to me that Firebird might benefit from a piece of technology I call
cycle lock. Here is a description of the motivation and the technique.
Falcon, NuoDB, and AmorphousDB all use a hash table to map transaction
ids into
On 3/21/2014 12:18 PM, Leyne, Sean wrote:
Sub-objects (parameters, columns, constraints) and attributes (say, routine
source) are not tracked directly.
You should read system tables and compare (in before and after triggers).
How?
Yes I can create a trigger, but I can't read the
My original memory allocator reliably initialized memory to all zeros.
It saves a lot of code.
Note that Java follows the same convention for the same reasons.
All that said, the C++ new does not, and while I from time to time use
a custom, high performance new, it is just too dangerous to
The wolf in Manchester pleads not guilty. A cursory examination of the
Vulcan code exposed the following code snippet in MET_lookup_index_name:
if (!gen_id) {
strcpy (name, RDB$GENERATORS);
return;
}
Any student of wolf-code will understand that the
On 4/2/2014 5:28 AM, Vlad Khorsun wrote:
C
I think it will be not easy to implement from the Y-valve point of view
- i see no simple way to pass handles from one process
(coordinator) to another (worker). Especially, in the case of Classic Server.
Instead, i think, we could
On 4/2/2014 7:05 PM, Vlad Khorsun wrote:
On 4/2/2014 5:28 AM, Vlad Khorsun wrote:
C
I think it will be not easy to implement from the Y-valve point of
view - i see no simple way to pass handles from one
process
(coordinator) to another (worker). Especially, in the case of Classic
On 4/2/2014 8:01 PM, Leyne, Sean wrote:
you can adapt my FAQ example
http://itstop.pl/en-en/Porady/Firebird/FAQ2/FIRST-SNAPSHOT
but starting all transactions as First Snapshot transactions in many
connections where system is still working i suppose is quite to impossible
with it.
At first
On 4/3/2014 11:58 AM, Vlad Khorsun wrote:
Sean, the solution is simple and elegant: Capture the transaction state
information from the lead transaction using the transaction info
mechanism then import it to secondary connection transactions with the
transaction parameter block.
It
On 4/4/2014 9:43 AM, Dimitry Sibiryakov wrote:
04.04.2014 15:37, Alex Peshkoff wrote:
On 04/04/14 17:01, James Starkey wrote:
An alternate solution that is close is thread specific sub-pools, which is
nice because a thread specific sub-pool doesn't even need interlocked
instructions. It does
, 2014 at 12:57 AM, Jim Starkey j...@jimstarkey.net wrote:
On 4/3/2014 5:16 AM, marius adrian popa wrote:
I repost it here from Firebird-general
Just noticed Mozilla license v1.1
http://opensource.org/licenses/MPL-1.1 was upgraded to v 2.0 maybe is
time for firebird project to do so for all new
On 4/24/2014 6:19 AM, Dmitry Yemanov wrote:
All,
We're getting closer to the v3.0 feature freeze which is going to happen
this summer. Everything roadmapped for v3 but not implemented before the
deadline will be postponed. The next-after-v3 release is likely to
incorporate most of the postponed
On 4/29/2014 8:38 AM, Dimitry Sibiryakov wrote:
29.04.2014 14:24, Carlos H. Cantu wrote:
You are right about the DB design, but that's up to the user. You
dont and should not worry with this.
But the one who implements built-in replication will have to worry about
conflict
handling,
On 5/1/2014 11:45 PM, Dmitry Yemanov wrote:
2- In an version based database like Firebird each row will need to be read
to confirm the current value of the target field.
It's not about version based databases, it's just about our index
implementation. And there are possibilities to avoid
On 5/2/2014 3:25 PM, Vlad Khorsun wrote:
OK, the alternative to record lookups is to store the transaction id in
index. This would require an index insertion for all indexes defined on
a table even if the key value didn't change. It would also require a
corresponding index deletion for each
On 5/2/2014 3:25 PM, Vlad Khorsun wrote:
OK, the alternative to record lookups is to store the transaction id in
index. This would require an index insertion for all indexes defined on
a table even if the key value didn't change. It would also require a
corresponding index deletion for each
On 5/5/2014 11:53 AM, Dmitry Yemanov wrote:
05.05.2014 19:06, Jim Starkey wrote:
My sole reservation is that there can be information lost when a large
valued 64 integer is converted into a double to generate the index key.
AFAIR, int64 integers are not converted into double, they're
My original cache management scheme used a weighted LRU where a cache
hit would set the high order bit of an aging value in the BDB. Periodic
aging cycles would do a right shift of the aging values, ending up with
aging values that, to a large degree, represented the historical hit
rate. It
That's an impossible problem to solve, which is one of the many reasons
that retrievals consider the index to be potentially noisy.
That said, in the original implementation, at least, a transaction
couldn't commit until everything touched had been written. But what
constituted a write was
On 5/10/2014 10:43 AM, Adriano dos Santos Fernandes wrote:
On 10-05-2014 04:03, Molnár Attila wrote:
*VARIANT data type in PSQL*
This would be very easy to implement (variables only). What would be the
use cases?
Any place you need a variable.
I would argue against an explicit VARIANT type,
On 5/13/2014 6:08 AM, Dimitry Sibiryakov wrote:
Hello, All.
If a record has uncommitted head version created by active transaction
and some garbage
in backversions tail, can anyone (background GC thread, sweep or parallel
transaction)
wipe this garbage from the tail while the
On 5/13/2014 10:59 AM, Dimitry Sibiryakov wrote:
10.05.2014 14:03, Vlad Khorsun wrote:
As for A-B-A
updates i see no problem as there will be 3 separate index entries with own
tx numbers. Currently we also have 3 index entires for such scenario, btw.
Old IB's optimization to not store
On 5/13/2014 11:24 AM, Dimitry Sibiryakov wrote:
13.05.2014 17:10, Jim Starkey wrote:
On 5/13/2014 10:59 AM, Dimitry Sibiryakov wrote:
If I'm not mistaken, these repeating index entries works as a
reference counters and
allow to stop using staying list for indexes even in current code
On 5/27/2014 2:15 PM, Frank Schlottmann-Gödde wrote:
On 05/27/2014 02:58 PM, marius adrian popa wrote:
1.One of the feature that i wish from project is to migrate from svn to github
(serveral projects are on github and it's is a lot easier to
contribute : MariaDB , Postgresql ...)
Why do you
On 6/11/2014 1:23 PM, Jiri Cincura wrote:
Hi *,
is there some description how events work? From protocol POV. I'm
hunting some race condition in .NET driver and cannot understand
what's happening there. Sadly the code I'm looking at is like 7 years
old and nobody touched it since.
The basic
On 6/11/2014 3:52 PM, Jiri Cincura wrote:
I might need to go one layer down and understand how it's done on
wire protocol level.
I forgotten the details, so reading the code is best. I'm quite sure it
requires opening a second network connection to the server for
asynchronous notifications.
I disagree both with the interface design and this critique. Neither, to my
experience, makes any sense.
It is the normal to define interfaces as pure virtual classes, in short, as
abstract interfaces. The Java guys had the intelligence and insight to define
language constructs that define
wrote:
On 22/07/14 01:10, Jim Starkey wrote:
snip
The argument that a pure virtual interface is compiler specific has no
merit. The various C++ implementations have take the necessary and obvious
steps so that object modules compiled with different compilers cannot be
mixed
Public interface objects should be reference counted with a protected virtual
destructor.
There are no issues with overloaded functions, though they do complicate the
mapping from object method to flat function names. On balance, it's probably
best to avoid them.
Rtti is intended to salvage
Why do you care? The vtable is an implementation artifact that by design and
architecture is invisible.
Stop trying to be cute. Use the language in the manner it was designed to be
used.
In nearly two decades of heavy C++, the only time I've even look at it is the
JVM side of JNI.
If you
that
requires interpretation of Dwarf data. You run into include files with
comments like, If you aren't gdb, you shouldn't be looking at this file.
On Jul 22, 2014, at 8:20 AM, Jim Starkey j...@jimstarkey.net wrote:
Public interface objects should be reference counted with a protected
A very good rule of thumb is to never use int when defining stuff. Use int32_t
or int64_t or a project equivalent. If you don't no which, you shouldn't be
defining anything. Use of int is fine when iterating over something that is
absolutely never going to overflow.
I agree that size_t has
to be anything but pug-ugly, but
eventually I made an accomodation. It still use my own typedefs for major
scalars like TransId, RecordId, AttributeId, etc.
On Jul 22, 2014, at 2:42 PM, Jim Starkey j...@jimstarkey.net wrote:
I agree that size_t has no place in interfaces, ever. You should
No, it supported multiple active statements since Groton Database Systems time.
And before that, Rdb/ELN.
Why do people make up facts to bolster losing arguments?
On Jul 24, 2014, at 5:30 PM, Vlad Khorsun hv...@users.sourceforge.net wrote:
On 24-7-2014 19:27, Vlad Khorsun wrote:
As far
Why not just use the C++ binding of JDBC that I wrote for Vulcan?
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight
That is utter nonsense. If there weren't a possibility of multiple active
statements, there would be no need for naming statements,
This flies in the face of the Interbase/Firebird architecture that support an
arbitrary set of active/open statements from the datpy it was born.
On Jul 24,
That may have been what you meant, but it wasn't what you said.
On Jul 25, 2014, at 3:37 AM, Mark Rotteveel m...@lawinegevaar.nl wrote:
On Thu, 24 Jul 2014 23:08:56 -0300, Jim Starkey j...@jimstarkey.net
wrote:
No, it supported multiple active statements since Groton Database
Systems
a different question).
So, gentlemen and ladies, why another incompatible and non-standard interface?
On Jul 24, 2014, at 11:11 PM, Jim Starkey j...@jimstarkey.net wrote:
Why not just use the C++ binding of JDBC that I wrote for Vulcan
application and tool work.
On Jul 25, 2014, at 9:38 AM, Alex Peshkoff peshk...@mail.ru wrote:
On 07/25/14 06:11, Jim Starkey wrote:
Why not just use the C++ binding of JDBC that I wrote for Vulcan?
Main reason is that I wanted to have something more or less similar to
existing ISC API
:
On 07/25/14 06:11, Jim Starkey wrote:
Why not just use the C++ binding of JDBC that I wrote for Vulcan?
Main reason is that I wanted to have something more or less similar to
existing ISC API. Certainly removing such things as SQLDA and adding
interfaces-style replacement.
What about JDBC
Yemanov firebi...@yandex.ru wrote:
25.07.2014 18:43, Jim Starkey wrote:
If an interface is incompatible, existing applications have to be recoded.
If they need to be recoded, there isn't any real purpose to retaining an
interface style.
At the moment the new API and the legacy one
On Jul 28, 2014, at 6:23 AM, Alex Peshkoff peshk...@mail.ru wrote:
On 07/25/14 18:43, Jim Starkey wrote:
If an interface is incompatible, existing applications have to be recoded.
If they need to be recoded, there isn't any real purpose to retaining an
interface style.
For existing
On 7/31/2014 4:31 PM, Tom Coleman wrote:
When I first saw JSON, my first thought was that could be a game
changer. It would incur more overhead, but nobody would be forced to
use it.
And think of the appeal to all those script language programmers!
On reflection though, direct database
Yes, that has been often said, and it been often disputed. It has been
explained any number of times, but you continue to ignore the arguments.
I'll try once more. Try to pay attention.
It is true that difference C++ implementations have different vtables. It is
also true that it is
Uh, there wasn't a Firebird day one. Firebird came from Interbase which was
originally Groton Database Systems which was a follow on to DEC's Rdb/ELN, an
implementation of DSRI (DEC Standard Relational Interface). All defined the
remarkably stupid packed decimal data type and none implemented
The MySQL interface, like the implementation, is best described as C+, e.g.
code that goes through the C++ compiler be is devoid of any semblence of OO
programming principles.
On Aug 5, 2014, at 3:10 PM, Tom Coleman tcole...@autowares.com wrote:
On Aug 5, 2014, at 1:52 PM, Jim
Just as a matter of curiosity, is there an agreed on set of requirements for
the new interface? If not, may I suggest that one be drawn up and discussed?
It's very hard to measure the success of a design without knowing what it is
supposed to do.
Version number of what? The interface, the client implementation, the
protocol, the server, the engine, the ODS?
On Aug 7, 2014, at 1:44 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
Attached I put a refinement with:
- Alex's default base
- Rename underline to Impl
-
, Jim Starkey wrote:
Just as a matter of curiosity, is there an agreed on set of requirements for
the new interface? If not, may I suggest that one be drawn up and
discussed? It's very hard to measure the success of a design without
knowing what it is supposed to do.
There were (except
On Aug 8, 2014, at 9:05 AM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
On 08/08/2014 08:52, Jim Starkey wrote:
So, if I understand your original goals, again as an outsider, I would have
to say that your current interface proposal does not meet them. Each step
I think it is universally accepted that the Firebird interfaces should be OO.
I would like to remind folks that there are at least two ways to do this. One
is to define the interface in an OO language. But, as has been widely argued,
this is impossible to make compatible across the various
over quasi-language independent erzatz
vtables? Decide where you want to go then figure out how to get there and
design (or select) an interface accordingly.
On Aug 10, 2014, at 9:02 AM, Dmitry Yemanov firebi...@yandex.ru wrote:
10.08.2014 14:10, Jim Starkey wrote:
It is a fool's
On Aug 10, 2014, at 12:12 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
Writing wrappers around handlers is just something that does not make
sense in the easy-of-use point of view. If you disagree, I'm waiting for
your prototype here!
Uh, I've done at least a dozen.
It has been pointed out that the client and plugin APIs are used by different
types of developers for different purposes. You didn't respond, so it's hard
to know whether you disagreed, didn't understand the point, or just didn't care.
There is no benefit to forcing two completely different
Adriano, this is a completely inappropriate response. If you think he is
wrong, you must explain exactly why he is wrong. While reasoning carries
weight, person opinions do not.
So, if you think he is wrong, olease elaborate.
On Aug 11, 2014, at 7:48 AM, Adriano dos Santos Fernandes
, 2014, at 8:50 AM, Alex Peshkoff peshk...@mail.ru wrote:
On 08/11/14 15:18, Jim Starkey wrote:
Adriano, you are arguing that you are right and the rest of the world is
wrong.
COM is designed so any language can use it, but C++ can use either as
explicit vectors of method pointer
On Aug 11, 2014, at 11:49 AM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
COM is full of problems:
- UTF16
- HRESULT with TLS access to errors
- No real OOP, just object composing with QueryInterface
- Ref. counting for all sorts of objects
This what I mean by
written in
DY Delphi.
DY Dmitry
++1, as it already happens with UDFs (lots of them coded in Delphi).
[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br
DY 11.08.2014 18:18, Jim Starkey wrote:
Since plugins pretty much need to be compiled with the same
Exceptions are clearly an issue. Exception handling is specific to the C++
runtime and can't be handled by other languages. This is specific to COM
however, it applies to all cross language interfaces.
A COM solution would be to have all methods return a COM object (null for
success if no
You may be more interested in why something failed than just that it failed.
An error mechanism should play nicely with the status vector to expose as much
-- or as little as the user needs. Sometimes an error code is enough,
sometimes a full formatted compound message is required.
But a
Mark, this is how I think we got here. There is a compelling need to export
engine semantics of UDFs and other types of plugins. The obvious -- and
desireable way -- to do this is with abstract objects. Since there also needed
some minor work on primary interface, it seemed logical to unite
Sigh. There used to be database based system to create and edit messages and
generate header and message files. Very handy using a database to develop a
database system.
On Aug 12, 2014, at 9:34 AM, Dimitry Sibiryakov s...@ibphoenix.com wrote:
Hello, All.
Is there a simple
You are now quite close to COM. The primary difference is that COM is based on
immutable interfaces and you have a single squishy interface with explicit
interface version. After a few iterations, developers with have to track what
versions had which features to avoid calling things that
The length is passed so the protocol handlers neither need to parse nor even
understand BLR. If every transmission layer had to understand BLR, extending
it would be next to impossible.
Efficiency is part and parcel of good design.
On Aug 13, 2014, at 4:21 PM, Mark Rotteveel
. Still, it must servce the
existing API, which is embedded in countless thousands of application programs.
On Aug 14, 2014, at 4:49 AM, Alex Peshkoff peshk...@mail.ru wrote:
On 08/14/14 03:41, Jim Starkey wrote:
The length is passed so the protocol handlers neither need to parse nor even
As the original author of SLONG, ULONG, et al, might I suggest that you ditch
them all in favor of the standard and size explicit int64_t, int32_t, etc.?
Specific types for things like transaction id, record number, etc., make
perfectly good sense, but artificial types that vary from platform
No, that's not even close to true. If the only fields encypted were the
procedure and trigger source blobs, nothing would be inaccessible without the
key except those blobs.
Obviously you disagree. Please explain your logic.
On Sep 1, 2014, at 9:51 AM, Dimitry Sibiryakov s...@ibphoenix.com
How can you make an assessment without taking the time to understand it?
The Achilles heel of open source is the drive to be the first to kill a new
idea or to kill it the deadest. It made progress at MySQL almost impossible.
Even ideas as simple as stabilizing error codes across versions.
...@telesiscomputing.com.au
wrote:
Jim Starkey wrote:
How can you make an assessment without taking the time to
understand it?
I understand enough to know that all of the options mean
intercepting reads and/or writes to the source field.
Any form of obscuring encryption you want to add to the
read/write
I think that would do it. Simplest idea so far.
Anybody see any problems with it? Anyone have a simpler solution?
On Sep 1, 2014, at 11:35 AM, Geoff Worboys ge...@telesiscomputing.com.au
wrote:
Jim Starkey wrote:
Sorry, if you had been paying attention, you would have
noticed
On Sep 1, 2014, at 4:42 PM, Dmitry Yemanov firebi...@yandex.ru wrote:
02.09.2014 00:22, James Starkey wrote:
What possible user applications are going to be doing procedure and
trigger definitions that require the source be omitted?
Whatever user application that works with the
in a script. The
negative is that it is not backwards compatible and will cause a syntax error
on previous versions.
On Sep 2, 2014, at 1:42 AM, Dmitry Yemanov firebi...@yandex.ru wrote:
02.09.2014 01:23, Jim Starkey wrote:
Whatever user application that works with the database and executes
Dalton, it's theoretically impossible to hide something with system
privileges and without encryption on an open source product. All that's
necessary is for someone to compile a version without checks. Now, it
is true that we're only trying to protect the source from people too
ignorant or
1 - 100 of 218 matches
Mail list logo
