You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by "Oliver B. Fischer" <o....@swe-blog.net> on 2014/12/16 09:07:35 UTC
Overhauling the Resource interface
Dear all,
while thinking about different scenarios I think the Resource interface
is a little bit to much oriented to file based resources.
public interface Resource {
boolean exists();
boolean isReadable();
boolean isOpen();
URL getURL() throws IOException;
URI getURI() throws IOException;
File getFile() throws IOException;
long contentLength() throws IOException;
long lastModified() throws IOException;
Resource createRelative(String relativePath) throws IOException;
String getFilename();
String getDescription();
}
How to handle configuration resources overhanded via REST? There is no
filename, no modification date.
I suppose the remodel this interface to be more generic and to be not so
much file system oriented.
WDYT?
Oliver
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Overhauling the Resource interface
Posted by Werner Keil <we...@gmail.com>.
+1
When we started DeviceMap the original concept of the DDR file (as defined
by the W3C) was always a (local) XML, but more recent versions of the
DeviceMap client also pay tribute to the fact it can be a URL provided by
some "Web Service" or contained inside a JAR, WAR or EAR.
Werner
On Tue, Dec 16, 2014 at 2:57 PM, Anatole Tresch <at...@gmail.com> wrote:
>
> Its an inputstream. Using the wrong encoding might get invalid results. Xml
> and properties should be fine because encoding is defined...
> Bur for custom formats...?
>
> Lets we what the others think. Brw the Description I would remove as well..
>
> A
> Oliver B. Fischer <o....@swe-blog.net> schrieb am Di., 16. Dez. 2014
> um 14:53:
>
> > @anatole: I also thought about adding MimeType. Encoding? Maybe.
> >
> > Closeable +1
> >
> >
> > Am 16.12.14 um 10:12 schrieb Anatole Tresch:
> > > Hi all,
> > >
> > > just as information (this does not mean it is perfect): the interface
> is
> > a
> > > direct copy from the Spring IO resource interface.
> > > @Oli: *String getFilename()* return a file name, if possible, or a
> > useless
> > > name, it is also used as input for toString() -> see javadoc I think.
> > > @Romain:
> > >
> > > Closeable +1
> > >
> > > Other improvements:
> > > - add MIME type of the resource
> > > - add encoding
> > >
> > > Last modified can be delivered with the HTTP header. Nevertheless I
> think
> > > we can strip it down to:
> > >
> > > >
> > > I suppose the remodel this interface to be more generic and to be not
> so
> > >> much file system oriented.
> > > -> You can try, but please do it along with the code. Some of the
> methods
> > > are used by the resource location/pattern resolver code. This codes
> works
> > > fine and has proven in thousands of projects (Spring). When you remove
> a
> > > method, you will have adapt the code there, so all is working again.
> When
> > > ask me personally, I will focus efforts on other aspects than this
> one...
> > >
> > > -Anatole
> > >
> > >
> > > 2014-12-16 9:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> > >> Hmm, agree + defining a custom resource I don't want to define an URL
> +
> > an
> > >> URI.
> > >>
> > >> createRelative shouldn't be in Resource but in a upper API
> > >> (filesystem/resourcemanager or anything) IMO
> > >>
> > >> I'd make it implement optionally
> > >>
> > >> Closeable, this way isOpen should be
> > >> useless (implementation detail)
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau
> > >> http://www.tomitribe.com
> > >> http://rmannibucau.wordpress.com
> > >> https://github.com/rmannibucau
> > >>
> > >>
> > >> 2014-12-16 9:07 GMT+01:00 Oliver B. Fischer <o.b.fischer@swe-blog.net
> >:
> > >>> Dear all,
> > >>>
> > >>> while thinking about different scenarios I think the Resource
> interface
> > >> is a
> > >>> little bit to much oriented to file based resources.
> > >>>
> > >>>
> > >>
> > >> public interface Resource {
> > >>> boolean exists();
> > >>> boolean isReadable();
> > >>> boolean isOpen();
> > >>> URL getURL() throws IOException;
> > >>> URI getURI() throws IOException;
> > >>> File getFile() throws IOException;
> > >>> long contentLength() throws IOException;
> > >>> long lastModified() throws IOException;
> > >>> Resource createRelative(String relativePath) throws IOException;
> > >>> String getFilename();
> > >>> String getDescription();
> > >>> }
> > >>>
> > >>> How to handle configuration resources overhanded via REST? There is
> no
> > >>> filename, no modification date.
> > >>>
> > >>>
> > >>
> > >> I suppose the remodel this interface to be more generic and to be not
> so
> > >>> much file system oriented.
> > >>>
> > >>> WDYT?
> > >>>
> > >>> Oliver
> > >>>
> > >>> --
> > >>> N Oliver B. Fischer
> > >>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > >>> P +49 30 44793251
> > >>> M +49 178 7903538
> > >>> E o.b.fischer@swe-blog.net
> > >>> S oliver.b.fischer
> > >>> J oliver.b.fischer@jabber.org
> > >>> X http://xing.to/obf
> > >>>
> > >
> >
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > X http://xing.to/obf
> >
> >
>
Re: Overhauling the Resource interface
Posted by Anatole Tresch <at...@gmail.com>.
Its an inputstream. Using the wrong encoding might get invalid results. Xml
and properties should be fine because encoding is defined...
Bur for custom formats...?
Lets we what the others think. Brw the Description I would remove as well..
A
Oliver B. Fischer <o....@swe-blog.net> schrieb am Di., 16. Dez. 2014
um 14:53:
> @anatole: I also thought about adding MimeType. Encoding? Maybe.
>
> Closeable +1
>
>
> Am 16.12.14 um 10:12 schrieb Anatole Tresch:
> > Hi all,
> >
> > just as information (this does not mean it is perfect): the interface is
> a
> > direct copy from the Spring IO resource interface.
> > @Oli: *String getFilename()* return a file name, if possible, or a
> useless
> > name, it is also used as input for toString() -> see javadoc I think.
> > @Romain:
> >
> > Closeable +1
> >
> > Other improvements:
> > - add MIME type of the resource
> > - add encoding
> >
> > Last modified can be delivered with the HTTP header. Nevertheless I think
> > we can strip it down to:
> >
> > >
> > I suppose the remodel this interface to be more generic and to be not so
> >> much file system oriented.
> > -> You can try, but please do it along with the code. Some of the methods
> > are used by the resource location/pattern resolver code. This codes works
> > fine and has proven in thousands of projects (Spring). When you remove a
> > method, you will have adapt the code there, so all is working again. When
> > ask me personally, I will focus efforts on other aspects than this one...
> >
> > -Anatole
> >
> >
> > 2014-12-16 9:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> >> Hmm, agree + defining a custom resource I don't want to define an URL +
> an
> >> URI.
> >>
> >> createRelative shouldn't be in Resource but in a upper API
> >> (filesystem/resourcemanager or anything) IMO
> >>
> >> I'd make it implement optionally
> >>
> >> Closeable, this way isOpen should be
> >> useless (implementation detail)
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2014-12-16 9:07 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> >>> Dear all,
> >>>
> >>> while thinking about different scenarios I think the Resource interface
> >> is a
> >>> little bit to much oriented to file based resources.
> >>>
> >>>
> >>
> >> public interface Resource {
> >>> boolean exists();
> >>> boolean isReadable();
> >>> boolean isOpen();
> >>> URL getURL() throws IOException;
> >>> URI getURI() throws IOException;
> >>> File getFile() throws IOException;
> >>> long contentLength() throws IOException;
> >>> long lastModified() throws IOException;
> >>> Resource createRelative(String relativePath) throws IOException;
> >>> String getFilename();
> >>> String getDescription();
> >>> }
> >>>
> >>> How to handle configuration resources overhanded via REST? There is no
> >>> filename, no modification date.
> >>>
> >>>
> >>
> >> I suppose the remodel this interface to be more generic and to be not so
> >>> much file system oriented.
> >>>
> >>> WDYT?
> >>>
> >>> Oliver
> >>>
> >>> --
> >>> N Oliver B. Fischer
> >>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> >>> P +49 30 44793251
> >>> M +49 178 7903538
> >>> E o.b.fischer@swe-blog.net
> >>> S oliver.b.fischer
> >>> J oliver.b.fischer@jabber.org
> >>> X http://xing.to/obf
> >>>
> >
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Overhauling the Resource interface
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
@anatole: I also thought about adding MimeType. Encoding? Maybe.
Closeable +1
Am 16.12.14 um 10:12 schrieb Anatole Tresch:
> Hi all,
>
> just as information (this does not mean it is perfect): the interface is a
> direct copy from the Spring IO resource interface.
> @Oli: *String getFilename()* return a file name, if possible, or a useless
> name, it is also used as input for toString() -> see javadoc I think.
> @Romain:
>
> Closeable +1
>
> Other improvements:
> - add MIME type of the resource
> - add encoding
>
> Last modified can be delivered with the HTTP header. Nevertheless I think
> we can strip it down to:
>
> >
> I suppose the remodel this interface to be more generic and to be not so
>> much file system oriented.
> -> You can try, but please do it along with the code. Some of the methods
> are used by the resource location/pattern resolver code. This codes works
> fine and has proven in thousands of projects (Spring). When you remove a
> method, you will have adapt the code there, so all is working again. When
> ask me personally, I will focus efforts on other aspects than this one...
>
> -Anatole
>
>
> 2014-12-16 9:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>> Hmm, agree + defining a custom resource I don't want to define an URL + an
>> URI.
>>
>> createRelative shouldn't be in Resource but in a upper API
>> (filesystem/resourcemanager or anything) IMO
>>
>> I'd make it implement optionally
>>
>> Closeable, this way isOpen should be
>> useless (implementation detail)
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-16 9:07 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>> Dear all,
>>>
>>> while thinking about different scenarios I think the Resource interface
>> is a
>>> little bit to much oriented to file based resources.
>>>
>>>
>>
>> public interface Resource {
>>> boolean exists();
>>> boolean isReadable();
>>> boolean isOpen();
>>> URL getURL() throws IOException;
>>> URI getURI() throws IOException;
>>> File getFile() throws IOException;
>>> long contentLength() throws IOException;
>>> long lastModified() throws IOException;
>>> Resource createRelative(String relativePath) throws IOException;
>>> String getFilename();
>>> String getDescription();
>>> }
>>>
>>> How to handle configuration resources overhanded via REST? There is no
>>> filename, no modification date.
>>>
>>>
>>
>> I suppose the remodel this interface to be more generic and to be not so
>>> much file system oriented.
>>>
>>> WDYT?
>>>
>>> Oliver
>>>
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fischer@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fischer@jabber.org
>>> X http://xing.to/obf
>>>
>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Overhauling the Resource interface
Posted by Romain Manni-Bucau <rm...@gmail.com>.
No as mandatory. I dont want to reread while lastmodified didnt change with
remote resources.
Le 16 déc. 2014 23:08, "Oliver B. Fischer" <o....@swe-blog.net> a
écrit :
> Seriously, do you think it has a benefit?
>
> Am 16.12.14 um 22:07 schrieb Romain Manni-Bucau:
>
>> I guess we would even make cached and thread safe finally,no?
>> Le 16 déc. 2014 21:48, "Oliver B. Fischer" <o....@swe-blog.net> a
>> écrit :
>>
>> May it should be possible to read Resource multiple times? So any
>>> consumer
>>> would be able to read the resource multiple times. So we could implement
>>> a
>>> any kind of optimistic consumption.
>>>
>>> wdyt?
>>>
>>> Oliver
>>>
>>> Am 16.12.14 um 10:12 schrieb Anatole Tresch:
>>>
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fischer@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fischer@jabber.org
>>> X http://xing.to/obf
>>>
>>>
>>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Overhauling the Resource interface
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
Seriously, do you think it has a benefit?
Am 16.12.14 um 22:07 schrieb Romain Manni-Bucau:
> I guess we would even make cached and thread safe finally,no?
> Le 16 déc. 2014 21:48, "Oliver B. Fischer" <o....@swe-blog.net> a
> écrit :
>
>> May it should be possible to read Resource multiple times? So any consumer
>> would be able to read the resource multiple times. So we could implement a
>> any kind of optimistic consumption.
>>
>> wdyt?
>>
>> Oliver
>>
>> Am 16.12.14 um 10:12 schrieb Anatole Tresch:
>>
>> --
>> N Oliver B. Fischer
>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>> P +49 30 44793251
>> M +49 178 7903538
>> E o.b.fischer@swe-blog.net
>> S oliver.b.fischer
>> J oliver.b.fischer@jabber.org
>> X http://xing.to/obf
>>
>>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Overhauling the Resource interface
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I guess we would even make cached and thread safe finally,no?
Le 16 déc. 2014 21:48, "Oliver B. Fischer" <o....@swe-blog.net> a
écrit :
> May it should be possible to read Resource multiple times? So any consumer
> would be able to read the resource multiple times. So we could implement a
> any kind of optimistic consumption.
>
> wdyt?
>
> Oliver
>
> Am 16.12.14 um 10:12 schrieb Anatole Tresch:
>
>> Hi all,
>>
>> just as information (this does not mean it is perfect): the interface is a
>> direct copy from the Spring IO resource interface.
>> @Oli: *String getFilename()* return a file name, if possible, or a useless
>> name, it is also used as input for toString() -> see javadoc I think.
>> @Romain:
>>
>> Closeable +1
>>
>> Other improvements:
>> - add MIME type of the resource
>> - add encoding
>>
>> Last modified can be delivered with the HTTP header. Nevertheless I think
>> we can strip it down to:
>>
>> >
>> I suppose the remodel this interface to be more generic and to be not so
>>
>>> much file system oriented.
>>>
>> -> You can try, but please do it along with the code. Some of the methods
>> are used by the resource location/pattern resolver code. This codes works
>> fine and has proven in thousands of projects (Spring). When you remove a
>> method, you will have adapt the code there, so all is working again. When
>> ask me personally, I will focus efforts on other aspects than this one...
>>
>> -Anatole
>>
>>
>> 2014-12-16 9:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>>
>>> Hmm, agree + defining a custom resource I don't want to define an URL +
>>> an
>>> URI.
>>>
>>> createRelative shouldn't be in Resource but in a upper API
>>> (filesystem/resourcemanager or anything) IMO
>>>
>>> I'd make it implement optionally
>>>
>>> Closeable, this way isOpen should be
>>> useless (implementation detail)
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2014-12-16 9:07 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>>
>>>> Dear all,
>>>>
>>>> while thinking about different scenarios I think the Resource interface
>>>>
>>> is a
>>>
>>>> little bit to much oriented to file based resources.
>>>>
>>>>
>>>>
>>> public interface Resource {
>>>
>>>> boolean exists();
>>>> boolean isReadable();
>>>> boolean isOpen();
>>>> URL getURL() throws IOException;
>>>> URI getURI() throws IOException;
>>>> File getFile() throws IOException;
>>>> long contentLength() throws IOException;
>>>> long lastModified() throws IOException;
>>>> Resource createRelative(String relativePath) throws IOException;
>>>> String getFilename();
>>>> String getDescription();
>>>> }
>>>>
>>>> How to handle configuration resources overhanded via REST? There is no
>>>> filename, no modification date.
>>>>
>>>>
>>>>
>>> I suppose the remodel this interface to be more generic and to be not so
>>>
>>>> much file system oriented.
>>>>
>>>> WDYT?
>>>>
>>>> Oliver
>>>>
>>>> --
>>>> N Oliver B. Fischer
>>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>>> P +49 30 44793251
>>>> M +49 178 7903538
>>>> E o.b.fischer@swe-blog.net
>>>> S oliver.b.fischer
>>>> J oliver.b.fischer@jabber.org
>>>> X http://xing.to/obf
>>>>
>>>>
>>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>
>
Re: Overhauling the Resource interface
Posted by "Oliver B. Fischer" <o....@swe-blog.net>.
May it should be possible to read Resource multiple times? So any
consumer would be able to read the resource multiple times. So we could
implement a any kind of optimistic consumption.
wdyt?
Oliver
Am 16.12.14 um 10:12 schrieb Anatole Tresch:
> Hi all,
>
> just as information (this does not mean it is perfect): the interface is a
> direct copy from the Spring IO resource interface.
> @Oli: *String getFilename()* return a file name, if possible, or a useless
> name, it is also used as input for toString() -> see javadoc I think.
> @Romain:
>
> Closeable +1
>
> Other improvements:
> - add MIME type of the resource
> - add encoding
>
> Last modified can be delivered with the HTTP header. Nevertheless I think
> we can strip it down to:
>
> >
> I suppose the remodel this interface to be more generic and to be not so
>> much file system oriented.
> -> You can try, but please do it along with the code. Some of the methods
> are used by the resource location/pattern resolver code. This codes works
> fine and has proven in thousands of projects (Spring). When you remove a
> method, you will have adapt the code there, so all is working again. When
> ask me personally, I will focus efforts on other aspects than this one...
>
> -Anatole
>
>
> 2014-12-16 9:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>> Hmm, agree + defining a custom resource I don't want to define an URL + an
>> URI.
>>
>> createRelative shouldn't be in Resource but in a upper API
>> (filesystem/resourcemanager or anything) IMO
>>
>> I'd make it implement optionally
>>
>> Closeable, this way isOpen should be
>> useless (implementation detail)
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-12-16 9:07 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
>>> Dear all,
>>>
>>> while thinking about different scenarios I think the Resource interface
>> is a
>>> little bit to much oriented to file based resources.
>>>
>>>
>>
>> public interface Resource {
>>> boolean exists();
>>> boolean isReadable();
>>> boolean isOpen();
>>> URL getURL() throws IOException;
>>> URI getURI() throws IOException;
>>> File getFile() throws IOException;
>>> long contentLength() throws IOException;
>>> long lastModified() throws IOException;
>>> Resource createRelative(String relativePath) throws IOException;
>>> String getFilename();
>>> String getDescription();
>>> }
>>>
>>> How to handle configuration resources overhanded via REST? There is no
>>> filename, no modification date.
>>>
>>>
>>
>> I suppose the remodel this interface to be more generic and to be not so
>>> much file system oriented.
>>>
>>> WDYT?
>>>
>>> Oliver
>>>
>>> --
>>> N Oliver B. Fischer
>>> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
>>> P +49 30 44793251
>>> M +49 178 7903538
>>> E o.b.fischer@swe-blog.net
>>> S oliver.b.fischer
>>> J oliver.b.fischer@jabber.org
>>> X http://xing.to/obf
>>>
>
--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fischer@swe-blog.net
S oliver.b.fischer
J oliver.b.fischer@jabber.org
X http://xing.to/obf
Re: Overhauling the Resource interface
Posted by Anatole Tresch <at...@gmail.com>.
Hi all,
just as information (this does not mean it is perfect): the interface is a
direct copy from the Spring IO resource interface.
@Oli: *String getFilename()* return a file name, if possible, or a useless
name, it is also used as input for toString() -> see javadoc I think.
@Romain:
Closeable +1
Other improvements:
- add MIME type of the resource
- add encoding
Last modified can be delivered with the HTTP header. Nevertheless I think
we can strip it down to:
>
I suppose the remodel this interface to be more generic and to be not so
> much file system oriented.
-> You can try, but please do it along with the code. Some of the methods
are used by the resource location/pattern resolver code. This codes works
fine and has proven in thousands of projects (Spring). When you remove a
method, you will have adapt the code there, so all is working again. When
ask me personally, I will focus efforts on other aspects than this one...
-Anatole
2014-12-16 9:13 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
>
> Hmm, agree + defining a custom resource I don't want to define an URL + an
> URI.
>
> createRelative shouldn't be in Resource but in a upper API
> (filesystem/resourcemanager or anything) IMO
>
> I'd make it implement optionally
>
> Closeable, this way isOpen should be
> useless (implementation detail)
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-12-16 9:07 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> > Dear all,
> >
> > while thinking about different scenarios I think the Resource interface
> is a
> > little bit to much oriented to file based resources.
> >
> >
>
> public interface Resource {
> > boolean exists();
> > boolean isReadable();
> > boolean isOpen();
> > URL getURL() throws IOException;
> > URI getURI() throws IOException;
> > File getFile() throws IOException;
> > long contentLength() throws IOException;
> > long lastModified() throws IOException;
> > Resource createRelative(String relativePath) throws IOException;
> > String getFilename();
> > String getDescription();
> > }
> >
> > How to handle configuration resources overhanded via REST? There is no
> > filename, no modification date.
> >
> >
>
> I suppose the remodel this interface to be more generic and to be not so
> > much file system oriented.
> >
> > WDYT?
> >
> > Oliver
> >
> > --
> > N Oliver B. Fischer
> > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> > P +49 30 44793251
> > M +49 178 7903538
> > E o.b.fischer@swe-blog.net
> > S oliver.b.fischer
> > J oliver.b.fischer@jabber.org
> > 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*
Re: Overhauling the Resource interface
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm, agree + defining a custom resource I don't want to define an URL + an URI.
createRelative shouldn't be in Resource but in a upper API
(filesystem/resourcemanager or anything) IMO
I'd make it implement optionally Closeable, this way isOpen should be
useless (implementation detail)
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-12-16 9:07 GMT+01:00 Oliver B. Fischer <o....@swe-blog.net>:
> Dear all,
>
> while thinking about different scenarios I think the Resource interface is a
> little bit to much oriented to file based resources.
>
> public interface Resource {
> boolean exists();
> boolean isReadable();
> boolean isOpen();
> URL getURL() throws IOException;
> URI getURI() throws IOException;
> File getFile() throws IOException;
> long contentLength() throws IOException;
> long lastModified() throws IOException;
> Resource createRelative(String relativePath) throws IOException;
> String getFilename();
> String getDescription();
> }
>
> How to handle configuration resources overhanded via REST? There is no
> filename, no modification date.
>
> I suppose the remodel this interface to be more generic and to be not so
> much file system oriented.
>
> WDYT?
>
> Oliver
>
> --
> N Oliver B. Fischer
> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
> P +49 30 44793251
> M +49 178 7903538
> E o.b.fischer@swe-blog.net
> S oliver.b.fischer
> J oliver.b.fischer@jabber.org
> X http://xing.to/obf
>