+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 <[email protected]> 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 <[email protected]> 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 <[email protected]>: > > >> 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 <[email protected] > >: > > >>> 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 [email protected] > > >>> S oliver.b.fischer > > >>> J [email protected] > > >>> 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 [email protected] > > S oliver.b.fischer > > J [email protected] > > X http://xing.to/obf > > > > >
