2012/7/9 Thomas Jungblut <[email protected]>
> Yes the naming is more than inconsistent.
> I thought we are going to add constants (for example) to the BSPInterface,
> so it isn't any more than just a marker interface.
> I would just remove the BSPInterface.
yes, that was my first thought too.
> Or is there another reason for it to
> be empty/existing?
>
IMHO just because the plain API should be based on interfaces rather than
on abstract classes.
Thus the BSPInterface could be refactored like follows :
/**
* The {@link BSPInterface} defines the basic operations needed to
implement a BSP
* based algorithm.
* The implementing algorithm takes {@link BSPPeer}s as parameters which are
* responsible for communication, reading K1-V1 inputs, collecting k2-V2
outputs
* and exchanging messages of type M.
*/
public interface BSPInterface<K1, V1, K2, V2, M extends Writable> {
/**
* This method is your computation method, the main work of your BSP
should be
* done here.
*
* @param peer Your BSPPeer instance.
* @throws java.io.IOException
* @throws org.apache.hama.bsp.sync.SyncException
* @throws InterruptedException
*/
public void bsp(BSPPeer<K1, V1, K2, V2, M> peer) throws IOException,
SyncException, InterruptedException;
/**
* This method is called before the BSP method. It can be used for setup
* purposes.
*
* @param peer Your BSPPeer instance.
* @throws IOException
*/
public void setup(BSPPeer<K1, V1, K2, V2, M> peer) throws IOException,
SyncException, InterruptedException;
/**
* This method is called after the BSP method. It can be used for
cleanup
* purposes. Cleanup is guranteed to be called after the BSP runs, even
in
* case of exceptions.
*
* @param peer Your BSPPeer instance.
* @throws IOException
*/
public void cleanup(BSPPeer<K1, V1, K2, V2, M> peer) throws IOException;
}
and consequently BSP would just be the same with javadoc being inherited
from the interface:
/**
* This class provides an abstract implementation of the {@link
BSPInterface}.
*/
public abstract class BSP<K1, V1, K2, V2, M extends Writable> implements
BSPInterface<K1, V1, K2, V2, M> {
/**
* {@inheritDoc}
*/
public abstract void bsp(BSPPeer<K1, V1, K2, V2, M> peer) throws
IOException,
SyncException, InterruptedException;
/**
* {@inheritDoc}
*/
public void setup(BSPPeer<K1, V1, K2, V2, M> peer) throws IOException,
SyncException, InterruptedException {
}
/**
* {@inheritDoc}
*/
public void cleanup(BSPPeer<K1, V1, K2, V2, M> peer) throws IOException
{
}
}
WDYT?
Tommaso
>
> 2012/7/9 Tommaso Teofili <[email protected]>
>
> > Hi all,
> >
> > I'd like to enhance our BSP API, the BSPInterface is currently useless as
> > it's only used by BSP and not providing any method signature.
> > So since we're meant to be backward compatibile, at least API wise, with
> > other Hama 0.x versions I'd propose to move the BSP methods' signatures
> in
> > the BSPInteracee and let the BSP class as it is (with no change on our
> most
> > used class :P):
> > Also I don't like the BSPInterface name, in the future I'd like more to
> > have the BSPInterface just called BSP and the current BSP be called
> > BSPBase/AbstractBSP but that should be done in a 1.0 version I think.
> > Another option would be to just remove the BSPInterface class and let
> > everything as it is in the BSP class, this would make sense but API wise
> > it's usually nice to have a plain interface define all the methods
> > contracts.
> >
> > What do you think?
> > Regards,
> > Tommaso
> >
>
