XML/RDF example config file

[Dan Brickley <Da...@bristol.ac.uk>]

I've knocked up a quick example in RDF format, and some notes explaining
what's going on as background for discussion. I've dropped these onto a
temporary web page as would be a little verbose to send the three docs
there to the list.

see:
	http://rudolf.opensource.ac.uk/~pldab/jakarta/

The gist is that RDF, whilst a little syntactically verbose, has some
nice properties that we might consider. Notably, it allows us to draw on
multiple metadata vocabularies whilst maintaining a simple conceptual
model (directed labelled graphs) and a clear syntax/model distinction.

If I get time, I'll draw out in ASCII art the underlying graph model
behind the data snippet shown. The embedded comments should make things
clear enough. I can expand on the examples and so on if people find this
at all useful...

have fun,

Dan



--
Daniel.Brickley@bristol.ac.uk                  
Institute for Learning and Research Technology http://www.ilrt.bris.ac.uk/
University of Bristol,  Bristol BS8 1TN, UK.   phone:+44(0)117-9287096

Re: XML/RDF example config file

[James Todd <ja...@eng.sun.com>]

i like this. i think dtd/xSchema/xLink/rdf all have merits
we should contiue to discuss.

- james

Dan Brickley wrote:
> 
> I've knocked up a quick example in RDF format, and some notes explaining
> what's going on as background for discussion. I've dropped these onto a
> temporary web page as would be a little verbose to send the three docs
> there to the list.
> 
> see:
>         http://rudolf.opensource.ac.uk/~pldab/jakarta/
> 
> The gist is that RDF, whilst a little syntactically verbose, has some
> nice properties that we might consider. Notably, it allows us to draw on
> multiple metadata vocabularies whilst maintaining a simple conceptual
> model (directed labelled graphs) and a clear syntax/model distinction.
> 
> If I get time, I'll draw out in ASCII art the underlying graph model
> behind the data snippet shown. The embedded comments should make things
> clear enough. I can expand on the examples and so on if people find this
> at all useful...
> 
> have fun,
> 
> Dan
> 
> --
> Daniel.Brickley@bristol.ac.uk
> Institute for Learning and Research Technology http://www.ilrt.bris.ac.uk/
> University of Bristol,  Bristol BS8 1TN, UK.   phone:+44(0)117-9287096
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

Re: tabs - can we not, please?

[Harish Prabandham <Ha...@eng.sun.com>]

+1 for 4 space indents
+1 for 8 space tabs
+1 for tabs converted to spaces..

- Harish

"Preston L. Bannister" wrote:

> Minor issue, but...
>
> It looks like at least some of the Jakarta sources are formatted using 8
> column tabs.  I would like to suggest that the Jakarta sources *not*
> contain TAB characters.
>
> If all your sources come from one place, or all you ever work on is one
> platform, then using tabs instead of spaces is no big deal.
>
> If your sources come from different places (naturally each choosing
> different tab settings :) and you might use serveral different editors
> in the course of one day - the indentation always comes out right if you
> use spaces instead of tabs.
>
> The flip side of this is you are more likely to get checkins with messed
> up indentation when using tabs...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

Re: tabs - can we not, please?

[Craig McClanahan <cm...@mytownnet.com>]

"Preston L. Bannister" wrote:

> Minor issue, but...
>
> It looks like at least some of the Jakarta sources are formatted using 8
> column tabs.  I would like to suggest that the Jakarta sources *not*
> contain TAB characters.
>
> If all your sources come from one place, or all you ever work on is one
> platform, then using tabs instead of spaces is no big deal.
>
> If your sources come from different places (naturally each choosing
> different tab settings :) and you might use serveral different editors
> in the course of one day - the indentation always comes out right if you
> use spaces instead of tabs.
>
> The flip side of this is you are more likely to get checkins with messed
> up indentation when using tabs...
>

Per the Guidelines page on source code
(http://jakarta.apache.org/guidelines/source.html) we are to be using the
"Code Conventions for the Java Programming Language" on Sun's web site.

The relevant rule is at the beginning of Section 4
(http://java.sun.com/docs/codeconv/html/CodeConventions.doc3.html), which
states:

    "Four spaces should be used as the unit of indentation.  The
    exact construction of the indentation (spaces vs. tabs) is
    unspecified.  Tabs must be set exactly every 8 spaces (not 4)."

So the current practice of constructing indentation out of spaces and/or
tabs is perfectly in accord with the specified standard, as long as you
correctly set your tab stops (every 8 spaces) for this code.  I'm neutral on
whether we change the standard to spaces-only or not, but I'm opposed to a
"cultural convention" in the group to violate the standard for details we
don't like.  There's several other rules in there I don't follow for my
personal code, but I'm obeying the listed conventions for Jakarta code
because that is what you do on multi-contributor projects.

Craig McClanahan

Re: tabs - can we not, please?

[David Brownell <da...@pacbell.net>]

> I have traded email with Scott Hommel (the current keeper of the coding standards), and he is very open to feedback. Further, he has no idea about the origin or reasoning behind the above paragraph and even hints that it will change in the near future. I will be suggesting a change to the coding standards to use tabs.

It's a standard with an extremely old tradition in UNIX (and hence on
the Internet ... as long as the "80 character line length" standard
(not obeyed by the above quote :-)

I could trace it back historically, but won't -- the point is that
eight spaces per tab is the only really widely adopted standard.

Briefly, without sticking to the conventional eight space tabs,
chaos reigns.  Likewise with line lengths.  (The line quoted above
doesn't format correctly in many widely used mail readers.)

- Dave

Re: tabs - can we not, please?

[Michal Mosiewicz <mi...@interdata.com.pl>]

Paul Philion wrote:
> [...]
> I have traded email with Scott Hommel (the current keeper of the coding standards), and he is very open to feedback. Further, he has no idea about the origin or reasoning behind the above paragraph and even hints that it will change in the near future. I will be suggesting a change to the coding standards to use tabs.

The origin of this paragraph is simple. In certain environments tab
cannot be anything more or less than 8 bytes. This was specifically very
true if you worked using terminals over the network etc. From long, long
time ago tab's been always 8 spaces.

As for indentation - it may be different. And usually indents are not
the same as tabs. It was never intended for tabs to function as indents
(unless we speak of keyboard use not ascii codes).

These coding standards are really useful. Just don't look at them from a
perspective of your prefered editor. The editor is not the only tool
that is commonly used. There are also issues like looking at cvs command
results, diffs, etc in your terminal, using those neat commandline tools
like cat, more, grep, find, etc. If you will assume that tabs aren't
just tabs, and you make them 4 spaces or you assign them other
functions, you will break a huge infrastructure that was being developed
for about 30 years or more.

It's not my intention to start any OS wars here, cause it's not the
right place. It's just a good sample of what those coding standard mean
in practice. Usuall coding standards discussions on lists related to
historically older platforms like unices are absolutely tab-problems
free. This problems doesn't exist there, becouse there are long lived
standards. This problem is related to platforms where
all-in-one-super-editors have become more popular. The fact is that each
Windows based integrated tool has it's own coding standards and they
tend to put less attention to what had existed before they were born.

-- Mike

Re: tabs - can we not, please?

[Ben Laurie <be...@algroup.co.uk>]

Paul Philion wrote:
> Further, I suggest adopting tabs here (1 tab = 4 spaces, all tabs for leading indents). Tools like jindent will make it very easy to clean up the code.

Noooo! This causes all sorts of problems. There's only One True
tabwidth, and that's 8 spaces. 4-space indents and 8-space tabs are also
the rule for Apache, BTW.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

Re: tabs - can we not, please?

[Paul Philion <ph...@acmerocket.com>]

I was looking over the Sun Java Coding Standards lately (which Jakarta is following, right?) where this is covered. The spec says:

    4 - Indentation

    Four spaces should be used as the unit of 
    indentation. The exact construction of the
    indentation (spaces vs. tabs) is unspecified.
    Tabs must be set exactly every 8 spaces (not
    4).

So according to the spec, all spaces is fine.

Now, on a personal note: I prefer to use all tabs, where one tab equals one level of indention. This keeps files smaller (fewer characters), gives indentation control to readers (some like 8 spaces, some like 2) who can set their own tabs. Finally, it is easier to set up many editors with simple tab indents.

I have traded email with Scott Hommel (the current keeper of the coding standards), and he is very open to feedback. Further, he has no idea about the origin or reasoning behind the above paragraph and even hints that it will change in the near future. I will be suggesting a change to the coding standards to use tabs.

Further, I suggest adopting tabs here (1 tab = 4 spaces, all tabs for leading indents). Tools like jindent will make it very easy to clean up the code.

- Paul Philion


"Preston L. Bannister" wrote:
> 
> Minor issue, but...
> 
> It looks like at least some of the Jakarta sources are formatted using 8
> column tabs.  I would like to suggest that the Jakarta sources *not*
> contain TAB characters.
> 
> If all your sources come from one place, or all you ever work on is one
> platform, then using tabs instead of spaces is no big deal.
> 
> If your sources come from different places (naturally each choosing
> different tab settings :) and you might use serveral different editors
> in the course of one day - the indentation always comes out right if you
> use spaces instead of tabs.
> 
> The flip side of this is you are more likely to get checkins with messed
> up indentation when using tabs...
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

tabs - can we not, please?

["Preston L. Bannister" <pr...@home.com>]

Minor issue, but...

It looks like at least some of the Jakarta sources are formatted using 8
column tabs.  I would like to suggest that the Jakarta sources *not*
contain TAB characters.

If all your sources come from one place, or all you ever work on is one
platform, then using tabs instead of spaces is no big deal.

If your sources come from different places (naturally each choosing
different tab settings :) and you might use serveral different editors
in the course of one day - the indentation always comes out right if you
use spaces instead of tabs.

The flip side of this is you are more likely to get checkins with messed
up indentation when using tabs...

Re: Security and Jakarta?

[co...@eng.sun.com]

>
>  - deep identifiers (like uuid's) for users and groups
>  - ACLs
>  - a logonUser() function
>  - a checkPermission() function
>
> Surely someone else has already been through this subject thoughly??
>
> The other problem (that Craig touched upon) is that the security database
> could reside in many places (the web server, the servlet engine, the
> application, the operating system, or a directory server) and the
> integration between them is spotty.

I think there are 2 issues:
- integration with the web server - we need to support "apache-authenticated"
users and the access model of Apache.

- servlet-security, checkPermission(), ACL - it is hard to do it without
Java1.2,
we need to reinvent Java1.2 security. This should be part of the framework.

Costin

Re: Security and Jakarta?

[Brett McLaughlin <ma...@hotmail.com>]

> "Preston L. Bannister" wrote:
>
> > I find myself in the position of writing a security API, to be called by
our
> > product's server-side code implemented using Java servlets.  I would
rather
> > not :), but that does not seem to be an option.
> >

<snip>

> >
> > The other problem (that Craig touched upon) is that the security
database
> > could reside in many places (the web server, the servlet engine, the
> > application, the operating system, or a directory server) and the
> > integration between them is spotty.
> >
>
> That's the rub, all right.  To me, security is one of the issues that a
"service
> provider interface" for the next generation of the servlet API should
address.
> Let's see how well my ASCII art works as I try to draw a picture of an
idealized
> architecture:
>
> Servlet  <-- 2.2 API -->  Servlet  <-- SPI for looking --> Security
>           (users, roles) Container     up user/role       Technology
>                                           answers           domain
>
> What the SPI should standardize is a portable interface for the servlet
> container to ask the questions it needs to satisfy the 2.2 servlet API
> semantics.  This is what I am doing for Tomcat specifically (see the
> org.apache.tomcat.security.RealmConnector interface in the CVS tree).
GIven
> such a standardized interface, you could plug your own security technology
> domain implementation that interacted with the underlying security data
via
> JNDI, JDBC, or whatever.  For clients that had legacy security
architectures
> into which you wished to integrate (this is going to happen a *lot*), you
would
> only need to code a custom component that implemented this interface.

Jon posted the gist of what I am, but it needed reinforcement - I think
trying to build a complete security API is well beyond the scope of the
Servlet API.  I agree with Craig (somewhat) that the basic idea is that the
servlet should be able to "ask questions" and not worry about how the
answers arrive to it.  There should be some external mechanism to do that,
though, as I do _not_ think that this should be specific to the Servlet
API... EJB, JavaMail, etc, should all be able to ask these same "questions"
and not have to depend on the Servlet API to do it.  This lies firmly in the
realm of a web framework...

...which is Turbine, as Jon mentioned.  We are working on getting this ready
to put out under Apache, so just realize that this is not a logical part of
the Servlet API project space, but belongs to the underlying we application
framework.  That framework is needed, and (we are working to make sure) it
will be there.  This is one of the cases where an assumption has to be made
that that application has some base services available to it.

-Brett

Re: Security and Jakarta?

[Craig McClanahan <cm...@mytownnet.com>]

"Preston L. Bannister" wrote:

> I find myself in the position of writing a security API, to be called by our
> product's server-side code implemented using Java servlets.  I would rather
> not :), but that does not seem to be an option.
>
> The bits added to security in the servlet 2.2 API spec are definitely a step
> in the right direction, but still a bit short of the mark.
>
> Mainly lacking:
>
>  - deep identifiers (like uuid's) for users and groups
>  - ACLs
>  - a logonUser() function
>  - a checkPermission() function
>
> Surely someone else has already been through this subject thoughly??
>
> The other problem (that Craig touched upon) is that the security database
> could reside in many places (the web server, the servlet engine, the
> application, the operating system, or a directory server) and the
> integration between them is spotty.
>

That's the rub, all right.  To me, security is one of the issues that a "service
provider interface" for the next generation of the servlet API should address.
Let's see how well my ASCII art works as I try to draw a picture of an idealized
architecture:

Servlet  <-- 2.2 API -->  Servlet  <-- SPI for looking --> Security
          (users, roles) Container     up user/role       Technology
                                          answers           domain

What the SPI should standardize is a portable interface for the servlet
container to ask the questions it needs to satisfy the 2.2 servlet API
semantics.  This is what I am doing for Tomcat specifically (see the
org.apache.tomcat.security.RealmConnector interface in the CVS tree).  GIven
such a standardized interface, you could plug your own security technology
domain implementation that interacted with the underlying security data via
JNDI, JDBC, or whatever.  For clients that had legacy security architectures
into which you wished to integrate (this is going to happen a *lot*), you would
only need to code a custom component that implemented this interface.

What the servlet API or SPI should *not* try to standardize, IMHO, is a complete
security realm architecture including the ability to create and modify users,
roles, and groups:

* The needs are too diverse to standardize
  a particular API.

* In cases of interoperating with legacy
  applications and security architectures,
  the machinery to maintain this stuff
  already exists, so there is no reason
  to duplicate it.

* In the case where the servlet container
  is built in to a larger application server
  (like a J2EE environment), you need to
  interact with the security architecture of
  the server itself, which will again have its
  own mechanisms to create and update
  security related information.

In the short term, of course, there is no standardized interface like this.  You
will either have to implement a linkage for each 2.2-compliant servlet container
you want to deploy on (assuming that such a linkage is even possible), or stick
with application-managed security and forego the 2.2 semantics.

Craig McClanahan

Re: Security and Jakarta?

[jon * <jo...@clearink.com>]

on 10/25/99 12:20 PM, jon * <jo...@clearink.com> wrote:

> This is all implemented (very well, I might add) in Dash.
> 
> <http://www.working-dogs.com/dash/>
> 
> For starters, take a look at com.workingdogs.dash.util.access.*

Speaking of which, I don't feel as though this stuff belongs in the Tomcat
code. It belongs in a web application framework and that is what we in the
JetSpeed group are calling "Turbine".

Essentially, as soon as I get time to do a final vote in the Java Apache
mailing list, Dash is going to be renamed Turbine and will be incorporated
officially into Java Apache.

-jon

Re: Security and Jakarta?

[jon * <jo...@clearink.com>]

on 10/25/99 12:00 PM, Preston L. Bannister <pr...@home.com> wrote:

> Mainly lacking:
> 
> - deep identifiers (like uuid's) for users and groups
> - ACLs
> - a logonUser() function
> - a checkPermission() function
> 
> Surely someone else has already been through this subject thoughly??

This is all implemented (very well, I might add) in Dash.

<http://www.working-dogs.com/dash/>

For starters, take a look at com.workingdogs.dash.util.access.*

-jon

RE: Security and Jakarta?

["Preston L. Bannister" <pr...@home.com>]

I find myself in the position of writing a security API, to be called by our
product's server-side code implemented using Java servlets.  I would rather
not :), but that does not seem to be an option.

The bits added to security in the servlet 2.2 API spec are definitely a step
in the right direction, but still a bit short of the mark.

Mainly lacking:

 - deep identifiers (like uuid's) for users and groups
 - ACLs
 - a logonUser() function
 - a checkPermission() function

Surely someone else has already been through this subject thoughly??

The other problem (that Craig touched upon) is that the security database
could reside in many places (the web server, the servlet engine, the
application, the operating system, or a directory server) and the
integration between them is spotty.

I *really* don't want to re-invent the wheel, but there seems to be a lack
of alternatives.  We will be shipping a servlet-based application to many
customers (hopefully :), would like to support more than one platform, and
need to work with the customer's preferred security scheme.

Re: Security and Jakarta?

[Craig McClanahan <cm...@mytownnet.com>]

"Preston L. Bannister" wrote:

> Has anyone given thought to security?
>

As a matter of fact, yes.

I proposed a change to Tomcat last Friday (on the TOMCAT-DEV mailing list) to
add a pluggable security architecture into Tomcat so that it could be support
security in stand-alone mode, or be easy to embed into other application
architectures.  Work on this is in progress.

>
> The com.sun.server.realm package (and friends) in Sun Java Web Server seems
> like a start, though it has some apparent shortcomings.
>

My design focus is a little more minimalistic than this -- it's to answer the
security-related questions mandated in the servlet 2.2 API spec for
HttpServletRequest:  getRemoteUser, isUserInRole(), and getUserPrincipal().  In
general, the implementation object that answers these questions will be an
adapter to some container specified security technology domain, and could even
reach back through the web server connector to interact with the web server's
own security architecture (this is what is planned for the Apache connector).

>
> I understand that Tomcat is pretty independent of the security
> implementation.  This is of most interest when Jetty3 gets folded into
> Jakarta, and we have a pretty complete web server.
>

It's pretty independent all right ... so independent that you have to integrate
it into some other server environment (like the J2EE reference implementation)
to have any security enforcement at all.  This will change once the work
discussed above is completed, and a nice pluggable interface will be provided.

Further discussions of this are occurring on TOMCAT-DEV.

Craig McClanahan

Security and Jakarta?

["Preston L. Bannister" <pr...@home.com>]

Has anyone given thought to security?

The com.sun.server.realm package (and friends) in Sun Java Web Server seems
like a start, though it has some apparent shortcomings.

I understand that Tomcat is pretty independent of the security
implementation.  This is of most interest when Jetty3 gets folded into
Jakarta, and we have a pretty complete web server.