Hehe, seems your answers are faster than mine - looks we have an agreement on URL ;)
2015-01-06 10:22 GMT+01:00 Romain Manni-Bucau <[email protected]>: > hehe > > [just cause I found it fun] > URI -> java.net.URI#toURL > [/] > > I understand you have concerns but I still dont get any of them. If we > take the Resource abstraction you proposed I see nothing mandatory - > compared to an URL. I also don't get why it is hard to extend, you > just pass a handler to a constructor. Last point: which case needs > this? Pretty sure the cases you mentionned will rely on their own > property source whatever format it is - I think to a rest service for > instance. For now - but once again I can miss something, just waiting > for your exemples - I just see it as a mathematical theory where we > just need a physical one - one which works for most of usages. > > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-01-06 10:13 GMT+01:00 Anatole Tresch <[email protected]>: > > No, this is not necessarily true. The decision was to not put it as part > of > > core. If other alternatives do not work, we may still discuss how we > solve > > our problem. I stated that I have concerns on the extendibility side of > > URLs, so if we dont't have really good answers to tackle that issues, we > > will have to look for another solution to solve the resource abstraction > > problem. There is a reason why Spring has done its abstraction. And it is > > not about Ant scripting per se, but lets keep away from that fundamental > > discussion and focus on the problem we want to solve: how to model > > resources in a unified, effective and extendible way, so we can let > formats > > (and probably other logic) consume them savily and with a common API. > > > > We could also try to use URIs as abstraction, which do not have the > > constraints about registered URL handlers, but we then must have some > logic > > that is able, e.g. to convert an URI into a input stream... > > > > So ideas are welcome! > > > > > > > > 2015-01-06 8:56 GMT+01:00 Romain Manni-Bucau <[email protected]>: > > > >> IIRC we agreed to move format in extensions so it means this is not > >> the selected solution, no? > >> > >> > >> Romain Manni-Bucau > >> @rmannibucau > >> http://www.tomitribe.com > >> http://rmannibucau.wordpress.com > >> https://github.com/rmannibucau > >> > >> > >> 2015-01-06 8:55 GMT+01:00 Oliver B. Fischer <[email protected]>: > >> > I found the discussion from two days ago. But I would like to see this > >> > discussed in a separate thread. At least I didn't see that we have a > >> common > >> > opinion on that. > >> > > >> > Oliver > >> > > >> > Am 06.01.15 um 08:29 schrieb Oliver B. Fischer: > >> > > >> >> Dear all, > >> >> > >> >> we have to clarify how do we find a property source at the end of the > >> day. > >> >> I have seen now three different apporaches: > >> >> > >> >> 1. org.apache.tamaya.format.ConfigurationFormat interface by Anatole > >> >> 2. Using an URL by Reinhard > >> >> 3. Custom interface by me for the JSON PropertySource > >> >> > >> >> The solution by Anatole and me is very similar and could be unified > >> >> easily. Independent of the way we go this interface belongs to the > core > >> >> module. Or not? > >> >> > >> >> Furthermore how does a normal Java SE user will use it? How does the > top > >> >> level usage of Tamaya looks like? > >> >> > >> >> Oliver > >> >> > >> >> > >> > > >> > -- > >> > N Oliver B. Fischer > >> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > >> > P +49 30 44793251 > >> > M +49 178 7903538 > >> > E [email protected] > >> > S oliver.b.fischer > >> > J [email protected] > >> > X http://xing.to/obf > >> > > >> > > > > > > > > -- > > *Anatole Tresch* > > Java Engineer & Architect, JSR Spec Lead > > Glärnischweg 10 > > CH - 8620 Wetzikon > > > > *Switzerland, Europe Zurich, GMT+1* > > *Twitter: @atsticks* > > *Blogs: **http://javaremarkables.blogspot.ch/ > > <http://javaremarkables.blogspot.ch/>* > > > > *Google: atsticksMobile +41-76 344 62 79* > -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79*
