Re: user management - why bother?
Roland Weber <[email protected]> Sat, 12 Jul 2008 15:17:58 +0200
| Newsgroups | gmane.comp.apache.incubator.projects |
|---|---|
| Message-ID | <[email protected]> |
Hi Angie,
> I personally think that LDAP might be overkill. To answer the question
> presented: why bother? To be able to keep photos public, protected or
> private. Public: anyone can view, protected: your friends can view,
> private: only you can view.
See, that's the problem... "protected: your friends can view".
"Friend" is not something that you can map to a J2EE role, like
HttpServletRequest.isUserInRole("Friend");
Every user has a different group of friends. If you want to
maintain such groups, you're right in the middle of user mgmt.
If you don't, you need to define an API where you are later
going to plug in this user management.
"Public" and "private" can be handled without user management.
If you use a system identity to connect to the JCR repository,
you can query and store the user identity via
HttpServletRequest.getRemoteUser() or
HttpServletRequest.getUserPrincipal().
How exactly these calls are mapped to the user registry depends
on the container and doesn't affect the application.
If you connect to the JCR repository with the user identity,
it depends on the ACL capabilities of the repository how to
implement those. Still, "public" and "private" are the two
things that I would expect to be available in any case.
If you have "friends" for a user, things change. You have to
consider more than the identity of the user that is logged in.
The "friend" relationship needs to be stored somewhere, and
it needs to be queried. You have to deal with the identities
of the users owning the photos and query their friends to see
whether the current user is among them. Or else you have to
query for the current user "whose friend am I?".
If you want to do that on the application level, you need
access to a user repository where you can query users and
groups. If you want to handle it on the repository level,
you'll find yourself implementing a Jackrabbit AccessManager.
The first option is ugly, the second one slightly off scope
for the moment (imho).
> I could probably be convinced that user
> management should be a 2.0 feature but it seems that it could be an
> important part of the end user experience.
I wasn't suggesting to delay it to 2.0. Rather 0.2, where
0.1 alpha 1 is the code you'll bring into the podling.
You have no developer community yet. My suggestion is
to focus on the core functionality while you grow that.
It's good to give thought to and keep an eye on everything,
but you don't have unlimited resources to get the job done.
The best way to get people interested is to deliver code
they can play with, code that works and can be extended.
If you're trying too many things at once, neither will
get finished.
cheers,
Roland