suggestion for Jigsaw2

Alexandre Rafalovitch writes:
 > This is just a thought.
 > 
 > Why auth catalog is treated in a very special way? Would it be better to
 > have it as a server module and to have some generic interface to it, so
 > other things could be added in similar fashion.
 > 
 > That would also solve the problem of not having a global coordinator
 > module between resources/filters (which some people asked about).
 > 
 > These modules would be loaded at the start and there would be some way to
 > access them. I believe Jeeves and James already have something similar(?).
 > 
 > Any comments?

Yes, I have started an implementation of such a thing. The idea is
that at init time, a resource get provided with a "context" and that
context can be queried for modules.

In fact the indexer is now (not distributed yet) such a module, so
typically a directory resource, to find which indexer it should use
would do something like:

class SomeDirectoryResource ... {

    init(InitContext context) {
        this.context = context;
    }

    Indexer getIndexer() {
        return (Indexer) context.getModule("w3c.jigsaw.indexer");
    }
}

[in 1.0alpha5 the context would be passed as an attribute, in Jigsaw
1.1 it wil be passed explicitly, as shown above]

Of course, loggers and other tools should probably be passed in the
same way; however, this - as I understand - doesn't affect the auth
module. Without going into to much details, the "auth module" in 1.1
will be splitted into two components:

a) a specific ResourceSpace (formely a ResourceStore) will be used to
   keep track of known users
b) Resources will (or at least should) be protected by acl
   (java.security.acl) *independently* of the handling of HTTP itself
   (as is *not* the case in 1.0alpha5)
c) The HTTP auth infos will allow to know which of the user (as
   handled in a) made the request). Once the user is know, we'll use
   b) to check the Acl for that user

Now about the goodies:
- ResourceSpace can be built out of *any* thing (ie a jdbc database,
   an ASCII file, a serialized object stream, etc). This means in
   particular that you can keep your user database at the place it's
   most convenient to you
- As resources are "extensible" through delegation (a resource will -
   should - be able to delegate parts of its state to another
   resource), you will be able to say create User resources out of
   /etc/password, and delete session tracking to another resource,
   perhaps stored through jdbc
- Wrt auth, as the auth functionality of a ResourceSpace (formerly
   ResourceStore) is no longer coupled with the HTTP handling itself,
   you will be able to use another protocol (ie RMI) to access them
   (ie configure them) while still having access controls.

Now, you may think this is over ambitious, I would certainly agree. I
think though it's worth trying because if all the "should" above
turns into "will", the resulting system might be rather cool ;-)

Anselm.
btw we arleady have parts of that new resource module including the
ascii and ObjectStream handling. Someone is working on a property
based resource space, and I hope to have a jdbc resource space really
soon.

Received on Friday, 16 May 1997 08:10:31 UTC