mina-ftpserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Latorre" <dvl...@gmail.com>
Subject Re: Patch for FTPSERVER-222
Date Thu, 20 Nov 2008 23:03:56 GMT
2008/11/20 Niklas Gustavsson <niklas@protocol7.com>

> On Thu, Nov 20, 2008 at 10:02 PM, Sai Pullabhotla
> <sai.pullabhotla@jmethods.com> wrote:
> > How about a scenario where I use two Ftplets one for access control
> > and another for logging? Potentially, I could buy these Ftplets from
> > two different vendors and I do not have access to the source code. So,
> > my logging Ftplet does not work as expected.
> Buying Ftplets from vendors... that would be the day :-)
> Anyways, I think you make a good case. David, you were in on the last
> discussion on this topic. What's your thoughts?

  I think Sai's suggestion makes sense. Although if you 'bought two Ftplet's
from different vendors' what would the logging ftplet do  when access is
denied ? Log that there was an unknown error ( that access was denied) ?
Probably the first ftplet did that already but providing  more
And then, if  different vendors provided you with  beforeCommand ftplets,
 we have the same case here, the first one in being executed can return a
SKIP or DISCONNECT result so the others won't be executed.

Anyway, there are several ideas, for example we could add another return
code which skips the command but executes the afterCommands.

 Anyway if we have the return code now (and we can guess from it that
everything worked! I should check if that's true ...) it is not that
important that we can SKIP everything.

Besides, we also can also implement some kind of "Exception handling ":
afterSuccessfulCommand(), afterCommandError(), afterCommand(). Last once
would execute always, the other ones just in case the command completed
correctly or an error occurred. This would allow us for a finer control of
the execution flow.  Maybe we could return a value in commands as well so we
can know if the command finished successfully.

Our FTPLets remind me very much of AOP, so let me  check how they implement
this kind of behaviour  ( do you know this?   , please step in!).

What are your thoughts?

> /niklas

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message