Mailing-List: contact dev-help@stanbol.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stanbol.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
Sender: me@farewellutopia.com
In-Reply-To: 
 <CA+_sZ+jkJR-GOUo1PzcjSuS1iVbPGzQpWCpuVV-bPRPViG19vw@mail.gmail.com>
References: 
 <CAEWfVJn4Jm-N6XwKLiB1sFPX3+YrzYvMT_tv9R6ehHGbkY0-ug@mail.gmail.com>
	<CALvhUEU_jo837Lq3DTHjbDP74iuT2NTvSrdthuOTXBAo-tFscQ@mail.gmail.com>
	<CA+_sZ+jkJR-GOUo1PzcjSuS1iVbPGzQpWCpuVV-bPRPViG19vw@mail.gmail.com>
Date: Mon, 8 Apr 2013 20:26:06 +0200
Message-ID: 
 <CALvhUEVHEn4Oi3c11MDn3voqBfoAxn8HjkEsiDwGTW36pDUF=g@mail.gmail.com>
Subject: Re: It's not security, but rather multi-user vs. single-user Stanbol
From: =?ISO-8859-1?Q?Reto_Bachmann=2DGm=FCr?= <reto@apache.org>
To: dev@stanbol.apache.org
Content-Type: multipart/alternative; boundary=f46d04016975ef4ada04d9dd918f

--f46d04016975ef4ada04d9dd918f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

Yet pronoun to dereference ;)

By "we" I wanted to refer to the Stanbol community. It was an attempt of a
reduction ad absurdum - but of course we theoretically could vote on
dropping the reusability goal for the components we build.

Cheers,
Reto

On Mon, Apr 8, 2013 at 4:01 PM, Fabian Christ
<christ.fabian@googlemail.com>wrote:

> Hi,
>
> perhaps it is really just security. Some people have the use case that
> they do want support for that others do not care. That's the pattern
> even if I do not understand who Reto refers to as "we" in his mail. As
> a community we should ensure that all can work on the things they want
> to.
>
> In any case, we have the process of opening issues if something is not
> working as expected for others. That's something concrete. If issues
> remain open for too long, we should take action. I think the community
> can expect the security guys to do their best to fix things as soon as
> they popup.
>
> 2013/4/8 Reto Bachmann-Gm=FCr <reto@apache.org>:
> > Hi Bertrand
> >
> > It's not just about about multi-user. Even we would say that we want
> > Stanbol only to be a stateless single-user engine we might still care
> about
> > handling java security correctly in case we want to support our modules
> > being integrated in other applications. So the issue would not just abo=
ut
> > doping authentication but also to significantly reduce reusability of t=
he
> > Stanbol components.
> >
> > Take for example a logging system. Typically a library that provides no
> > support for multiple-user. Yet such a library has to care about not
> > requiring any unexpected permission on logging.
> >
> > Cheers,
> > Reto
> >
> > On Mon, Apr 8, 2013 at 12:11 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org
> >> wrote:
> >
> >> Hi,
> >>
> >> I'm trying to understand the disconnect that we're seeing in the
> >> security discussions...isn't that more about the following two modes
> >> of using Stanbol?
> >>
> >> Single user Stanbol:
> >> A stateless engine that's accessed by trusted systems, which are
> >> supposed to handle security and access control by themselves
> >>
> >> Multi-user Stanbol:
> >> An engine that's accessed by non-trusted users and might store their
> >> data, so needs security features, user management, etc.
> >>
> >> Agreeing on these two usage modes might help us have more constructive
> >> discussions, IMO, about features that multi-user requires but
> >> single-user doesn't even want to see.
> >>
> >> -Bertrand
> >>
>
>
>
> --
> Fabian
> http://twitter.com/fctwitt
>

--f46d04016975ef4ada04d9dd918f--