mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Francia <and...@andreafrancia.it>
Subject Re: [FtpServer] User interface design
Date Wed, 01 Oct 2008 18:29:18 GMT
Niklas Gustavsson wrote:
>> From Andrea Francia
>>
>> Moreover I don't clearly see the difference between attempting authorizing a user
and know if a user is authorized to do something.
>> Could you explain me, please?
>>     
>
> One use case would be where you have an administration tool for
> FtpServer and would like to list users and there authorities.
>   
I think that the methods of the User interface should be divided in two 
categories:
 1. method that are called from ftpserver-core
 2. method that are called from something administration tool

While the methods of type 1 are mandatory to get a working FTP server 
the methods of type 2 are not.

For example I'm writing an FTPServerStub to be used in unit testing, I 
wont write an Authority[] getAuthorities() method. None call thesse 
methods, I never seen an Administration Tool for the Apache FTP Server 
and my classes are not designed to be administered (they are only for 
unit test purpouse).
Now, I known, after searching in the code of ftpserver-core that I could 
simply return nulls.
But a end user of the FTPlet library should read these informations from 
the docs.

The same will apply to the UserManager interface. I think that the 
UserManager#save() should be optional. Some UserManager could be read-only.

We can use the same solution used by the Java Collection Framework: some 
methods can be optionally implemented.
For example some methods of the List interface are optional:

From: 
http://java.sun.com/docs/books/tutorial/collections/interfaces/list.html
> public interface List<E> extends Collection<E> {
>     // Positional access
>     E get(int index);
>     E set(int index, E element);    //optional
>     boolean add(E element);         //optional
>     void add(int index, E element); //optional
>     E remove(int index);            //optional
>     boolean addAll(int index,
>         Collection<? extends E> c); //optional
>
>     // Search
>     int indexOf(Object o);
>     int lastIndexOf(Object o);
>
>     // Iteration
>     ListIterator<E> listIterator();
>     ListIterator<E> listIterator(int index);
>
>     // Range-view
>     List<E> subList(int from, int to);
> }
All optional methods have a javadoc like this:

    /**
     ....
     * @throws UnsupportedOperationException if the <tt>remove</tt> 
operation
     *         is not supported by this list
     */
    boolean remove(Object o);

>> Moreover I'm not convinced about the usage of AuthorizationRequest as a result type.
>> I see that the authorization request is used as a result to bring some values to
the caller, like the case of the TransferRateRequest that returns back the maxDownloadRate,
and the maxDownloadRate.
>> Why not a AuthorizationResult?
>>     
>
> This is modelled slightly after Spring Security. Request might not be
> a good name the interface, but the general idea is to sent a request
> and have the relevant authority fill in the details. As this is
> chained , we could not do a simple request/response pair.
>   
I don't know how the Spring Security wotks.
I don't understand what means that the result is chained.

Could someone explain it to me?

-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html


Mime
View raw message