Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of francois.orsini@gmail.com
 designates 64.233.182.196 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=JMAkiBbmkgBIEGszhnrxYjaqPCqcY9o5YzNJeuWJIV5agbVzdwmqPD1H5LxWwuyZGIgtHfnan5oGUqItggF8mnUPtXNDTJ7hR+fkz1CX6zD9vicU8T9jc7B6/Q5sHmwYGztPn+FdinYedqAOLBwyBalf0SodbzKj099O2ZfKabE=
Message-ID: <7921d3e40602281028k3c5048fdo3a336f552d9b2198@mail.gmail.com>
Date: Tue, 28 Feb 2006 10:28:34 -0800
From: "Francois Orsini" <francois.orsini@gmail.com>
To: derby-dev@db.apache.org
Subject: Re: Grant -revoke (464) and future backwards compat
In-Reply-To: <44045BAF.60409@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <43F4ECB5.2060206@apache.org> <43FA43A6.4070403@apache.org>
	 <43FAC925.9080708@sun.com> <43FB4E01.7050301@Sourcery.Org>
	 <44045BAF.60409@sun.com>

On 2/28/06, =D8ystein Gr=F8vlen <Oystein.Grovlen@sun.com> wrote:
> Satheesh Bandaram wrote:
>
> > Until these system privileges are ready, current proposal limits
> > accesses that would cause forward compatibility issues. If sqlStandard
> > mode allows unrestricted schema creation now, this would cause issues i=
n
> > the future where existing applications may need to change or we have to
> > introduce another property like what is being done now. Current legacy
> > authorization model is not compatible with standard model or what Derby
> > might really want to support, but at the same time, we can't drop
> > support for it because of existing applications. I believe Dan is try t=
o
> > ensure current proposal doesn't create any future compatibility issues,
> > even if in the short term, Derby's new capabilities are restrictive.
>
> My main concern here is usability.  As long as the legacy mode is the
> default, it seems OK to enforce such restrictions in sqlStandard mode
> since it will probably not hit unexperienced users.  Will legacy mode
> always be the default?  Do we plan to switch to sqlStandard mode at some
> point in time?
>

This would impact Ease of Use  which has always been key to the Derby
charter. It is nice to get a choice but it can also be confusing -
Authentication is turned off by default as well and this came from a
ease of use requirement, mostly for embedded environments...

> Another important aspect of usability is that a product behaves in a
> familiar way.  That is, the behavior is similar to similar products.  I
> am a bit concerned if users will need to know about a specific property
> in order to be able to use GRANT/REVOKE.  Also, can we really claim to
> be standards-compliant if one needs to set specific property in order to
> be able to use parts of the standard?
>

Good point but if you have a way to enforce that feature to be used
then I would think it is - If a feature is supported and can be
enforced in some RDBMS then I would think it is compliant but that's
just IMHO.

> I also note that while easy-to-use and standards-based is covered by the
> Derby Charter, backward-compatibility is not.  ;-)
>
> --
> =D8ystein
>
>