I don’t know if I like the configuration know how create store, but I really like the registration approach instead of ugly factory --  Daniel Passos On January 9, 2014 at 9:11:41 AM, Tadeas Kriz (tkriz(a)redhat.com) wrote: Hey, It’s me again with more changes to the DataManager API. I’ve tried many different approaches and this one is basically the only one I got to work as intended (these are only interfaces, no real implementation, but that’s not a problem as it won’t make it much difficult to change current implementations to match those interfaces). Basically, it’s not the best and I had better APIs, but they unfortunately weren’t possible because of restrictions in Java. You can find the draft here: https://gist.github.com/TadeasKriz/e0f5583e2a24c32dc253 What can I say about this API is, that in this approach the user shouldn’t need to cast the Store<T> (which is real pain in current API) unless he really needs to (like some methods that’ll be available only for the store he wants). In other cases, when the cast is not needed, users will be able to just work with the Store<T> and change the underlying store as they like. So let’s say they’ll be working with MemoryStore in development, because it’s easier to debug. Then the release will be closing in, they’ll just switch to SQLStore very easily. So, what do you think guys? — Tadeas Kriz tkriz(a)redhat.com _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

+1 --  Daniel Passos On January 13, 2014 at 12:23:53 PM, Tadeas Kriz (tkriz(a)redhat.com) wrote: It might not be named “Configuration”. It could be a “Builder” instead, how about that? — Tadeas Kriz tkriz(a)redhat.com On 13 Jan 2014, at 13:05, Daniel Passos <daniel(a)passos.me&gt; wrote: I don’t know if I like the configuration know how create store, but I really like the registration approach instead of ugly factory --  Daniel Passos On January 9, 2014 at 9:11:41 AM, Tadeas Kriz (tkriz(a)redhat.com) wrote: Hey, It’s me again with more changes to the DataManager API. I’ve tried many different approaches and this one is basically the only one I got to work as intended (these are only interfaces, no real implementation, but that’s not a problem as it won’t make it much difficult to change current implementations to match those interfaces). Basically, it’s not the best and I had better APIs, but they unfortunately weren’t possible because of restrictions in Java. You can find the draft here: https://gist.github.com/TadeasKriz/e0f5583e2a24c32dc253 What can I say about this API is, that in this approach the user shouldn’t need to cast the Store<T> (which is real pain in current API) unless he really needs to (like some methods that’ll be available only for the store he wants). In other cases, when the cast is not needed, users will be able to just work with the Store<T> and change the underlying store as they like. So let’s say they’ll be working with MemoryStore in development, because it’s easier to debug. Then the release will be closing in, they’ll just switch to SQLStore very easily. So, what do you think guys? — Tadeas Kriz tkriz(a)redhat.com _______________________________________________  aerogear-dev mailing list  aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev