Well... interfaces seem a lot more complicated then just pojos. Why would a pojo need to be an interface to begin with?
As for the AbstractGadgetData thing we really really need to get rid of that class, so that's a little bit of a separate issue. Ideally we would just use a java->json->java library which takes in any java object, and does not require inheritance. What we have right now is a very good stop gap solution. So why do you need to change the default pojo implementation of a pojo? Can you simply extend Person.java to do what you need? Any details would greatly help us all make a good design decision together. Thanks. - Cassie On Sun, Apr 20, 2008 at 4:39 PM, Ian Boston <[EMAIL PROTECTED]> wrote: > I guess this is really a question for Cassie.... > > How receptive would you be to extracting interfaces from the model area to > enable other implementation schemes. > > eg > all the classes in org.apache.shindig.opensocial.model become interfaces > the sample container provides an set of implementations bound to the > interfaces. > > AbstractGadgetData implements a GadgetData interface and that is used where > AbstractGadgetData is used. > > I can provide a patch... > > > Ian > > > >
