Hi Luciano, As you said, this is the suggestion to a refactored interface definition for FaceRecognitionService interface.
public void train(String uids); public void setFacebookOauth2(String fbUserId, String oauthToken); public void removeTags(String tids) ; public void saveTags(String tids, String uid, String label); public Photo recognizeFromFile(File file, String uids); public Photo recognizeFromUrls(String urls, String uids); public Photo detectFromFile(String file); public Photo detectFromUrls(String urls); public void clearTwitterCreds(); public void clearFacebookCreds(); These are the most frequently methods which is used and which can be used in future in face apps. No need any return type from train method as we only need a void from it. But in the impl of this, we need a class called "Photo" which will behaves similar to org.face4j.Photo . Because in future face apps, when need to call these methods separately, we need to pass an instance of "Photo" which can keep "Faces" from detecting or recognizing images. Otherwise for the requirements of my two face apps, the above API can further reduced and even can make this such that "Photo" is no need as a return type. But in future one might need it for simplicity. WDYT? Thanks On Mon, Aug 1, 2011 at 1:02 AM, Luciano Resende <[email protected]>wrote: > On Tue, Jul 26, 2011 at 10:06 PM, Luciano Resende <[email protected]> > wrote: > > On Tue, Jul 26, 2011 at 9:23 PM, Subash Chaturanga <[email protected]> > wrote: > >> FYI, > >> When I change the return type to String it works fine. But currently I > am > >> returning a face4j.Photo. Seems returning the type Photo from one > service > >> method to its parent method in another service is the problem. > >> Any ideas? > >> > > > > What photo looks like ? Is it serialazible ? > > > > > > Looking at [1], Photo seems to be a problematic pojo, it does not > properly provides getters and setters for all it's attributes, which > will cause issues for Tuscany/Jackson serialization/deserialization. > > My recommendation would be to put face4j on the side for couple mins, > define a independent set of service operations and required > information for these operations, and then for the implementation use > face4j. This would give us a clean Face Recognition Service interface, > and make the implementation much more flexible, as it would allow us > to change the implementation in the future as face4j would be > encapsulated in the service implementation. > > > [1] > https://github.com/mhendred/face4j/blob/master/face4j-core/src/main/java/com/github/mhendred/face4j/model/Photo.java > > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/ > -- Subash Chaturanga Department of Computer Science & Engineering University of Moratuwa Sri Lanka Blog - http://subashsdm.blogspot.com/ Twitter - http://twitter.com/subash89
