[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RDDL] Cache / Security Model
- From: Jonathan Borden <email@example.com>
- To: Jeff Rafter <firstname.lastname@example.org>, email@example.com
- Date: Mon, 29 Jan 2001 15:01:36 -0500
Jeff Rafter wrote:
> I have seen this group actually take on some of the more challenging,
> controversy laden, arguments lately with success, so I thought I would
> us on another. Should RDDL have a layer that implements a caching
> which contains: expiration dates, automatic lookup, namespace aliases,
> public/private key signing, options for turning off namespace resolution?
When trying to solve a difficult problem, I think it is best to subdivide
such a problem into solvable units. Hopefully RDDL solves a problem. Rather
than burden RDDL with other truly difficult problems, let's see how RDDL may
work with other solutions. At present RDDL is a document format. The issues
you raise involve protocols. In my view, software implementations as they
become increasingly sophisticated will hopefully provide solutions to the
real problems you address.
> My thinking is that this would address some of the biggest question marks
> left regarding RDDL. Such as:
> 1) Should the namespace be resolved blindly?-- I think yes, but if your
> parser implemented an RDDLCache with an RDDLSecurityLayer you could turn
> off if you disagree.
A 'RDDLCache' is a great idea for a client side implementation. Perhaps
something like BerkleyDB or another relatively lightweight client side
database can suck in RDDL documents, and perhaps this could be integrated
with a client side document cache.
> 2) Will usages of common namespaces (such as the XHTML or XML Schema
> namespaces) overload the Internet?-- Probably and having a caching system
> built into the resolution model would alleviate some of that. Namespace
> aliases could also help in this area-- they could point to a local cache
> another trusted server where the appropriate documents are stored.
Right, or as with today's browsers that first check the local cache.
> I think that the signing mechanism would be a great addition and might
> to satisfy some of the trust issues that have been brought up. I am
> in VERY simple terms right now, however-- not some overarching Internet
> changing system that takes months to agree upon. Only the basics with the
> mindset of developer extension.
> One possible extension would be an RDDLMap that would create an XML tree
> all included (nested) resources referred to by the RDDL-- it may even
> out circular references to namespaces-- just a thought.
The idea of developing a client side cache is right on (IMHO). My very
simple implementation uses trees because they are provided in JDK 1.2 (and
are available for JDK 1.1), but a lightweight client side table would solve
all the problems my implementation has and more.