Re: Some API related questions
Thanks Jerome for lending an ear. How can I best get to what you have already done? Should I wait for the next b-release or a nightly release (that would be cool)? I will need to change my classes now :) I will comment on/pursue these issues after I have used what's been done. Cheers Piyush On 8/9/06, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Piyush, [..] Now we are talking taste here but I think Java packages aren't a very good example because some of them are there since jdk 1.0 and can't be refactored without breaking thousands of apps ..I am pretty sure that the Sun Java API gurus don't sleep easy at night :) Good argument, I buy that...and I do want to get some rest this night ;-) We are building something new here so we can be a little more adventurous. And my opinion is that having more packages isn't a sin packages are there to organize classes and help in avoiding to create cyclical dependencies .. I agree, it's a matter of finding the right balance between too many classes per packages and too many 'empty' packages. so a default package may be needed grouping all the default implementations .. or maybe another package hierarchy? I think I'd like to keep defaut/abstract implementations close to their interface. But I'm open to adapting the packages structure if needed. One thing I wanted to ask too was why do you have Enum implementing Interfaces? Is that something you saw being done someplace? Enums are Enums and by implementing interfaces you are trying to bridge the gap between Enum and Class that was created in 1.5 in order to make the distinction clear. My intent was to leverage the enumeration introduced in 1.5. So I started adding enums for methods, statuses, media types, etc. But then I realized that I couldn't enumerate all the potential media types, etc. So I thought about a way to allow usage of enums while preserving the extensibility. The only way I found was to introduce interfaces implemented by both enums and default classes. The problem is that I opened the Pandora box: if you get a media type, you can't switch it because you have to work from the interface... OK, I will refactor all this into single classes with static members for common values. That should greatly reduce the size of the data package. And I have seen some empty marker interfaces (Data and ControlData) and as per Joshua Bloch (and I totally agree) empty marker interfaces usually lead to problems later ... Good point, I was not initially sure if those REST concepts would need an equivalent Java artifact. For now, I've removed all of them and we'll see if/why we need them back down the road. Did you file a bug report on that or did you use an existing one? I have the opinion this isn't a wise move as how will I accomplish adding servers that aren't DefaultServers (That is what ServerMap does) to the components? You missed the fact that ServerMap extends WrapperMapString, Server and implements MapString, Server. So you can do put(name, myServer). In addition, I've changed the ServerMap's implementation to use directly the Factory instead of using the DefaultServer. Same thing for ClientMap. And the ServerMap from connector package creates an unnecessary dependency on WrapperMap in package data. If you were to remove all those collection wrappers to another package collections or util (if you want to take java's example) you remove these unencessary dependencies between your core packages... I don't see an issue in having a dependency between connector and data as data elements are naturally exchanged between components using connectors. For example, you need the Client.post(String uri, Representation input) method. However, I agree that we shouldn't have cyclical dependencies, like from data to connector or component. We'll also remove the dependency from connector to component later. In the end we should have this dependency tree: org.restlet.component +- org.restlet.connector +- org.restlet +- org.restlet.data Create a package org.restlet.spi (Service provider interface) and move Factory there. This package now can have dependency on org.restlet and org.component and honestly on all the rest of them too .. no problem :) Having just one Factory class, let's see if we can get rid of an additional spi package. Best regards, Jerome
Re: Resources and Representations
Perhaps a WIKI on restlet.org with a general/open examples section would be great so that examples could be uploaded and discussions can be had on the uploaded examples.. I would then upload my solution to configuring components using an XML file (JAXB and handler classes). Chris could upload his example there... integrating a simple wiki with restlets would be a great example too!
RE: error running b18 on Simple
Hi Chris, Thanks for reporting this regression. It's fixed it in SVN. Make sure you fully refresh your local copy. Best regards, Jerome -Message d'origine- De : Chris Winters [mailto:[EMAIL PROTECTED] Envoyé : jeudi 10 août 2006 00:24 À : discuss@restlet.tigris.org Objet : error running b18 on Simple On grabbing b18 from svn and compiling, my sample app dies immediately on any request with: Aug 9, 2006 6:16:54 PM com.noelios.restlet.connector.AbstractHttpServer handle WARNING: Error while handling an HTTP server call: Aug 9, 2006 6:16:54 PM com.noelios.restlet.connector.AbstractHttpServer handle INFO: Error while handling an HTTP server call java.lang.NullPointerException at org.restlet.connector.AbstractServer.handle(AbstractServer.java:66) at com.noelios.restlet.connector.AbstractHttpServer.handle(Abstra ctHttpServer.java:86) at com.noelios.restlet.connector.AbstractHttpServer.handle(Abstra ctHttpServer.java:67) at com.noelios.restlet.ext.simple.SimpleServer.handle(SimpleServe r.java:134) at simple.http.Dispatcher.run(Unknown Source) at simple.util.process.Daemon.execute(Unknown Source) at simple.util.process.Daemon.run(Unknown Source) It looks like the 'target' property of AbstractServer isn't being assigned. Chris -- Chris Winters ([EMAIL PROTECTED]) Lead Software Developer Vocollect Healthcare Systems CONFIDENTIAL, PRIVILEGED COMMUNICATION: This e-mail is private and intended for the addressee(s) only. It may contain privileged and/or confidential information. If you have received it in error you are not authorized to disseminate it in any manner; please delete it and any copies and reply to the sender that it was misdirected.
RE: Some API related questions
Hi Piyush, There is a snapshot containing the latest changes at: http://www.restlet.org/downloads/current.zip Best regards, Jerome -Message d'origine- De : Piyush Purang [mailto:[EMAIL PROTECTED] Envoyé : jeudi 10 août 2006 11:35 À : discuss@restlet.tigris.org Objet : Re: Some API related questions Thanks Jerome for lending an ear. How can I best get to what you have already done? Should I wait for the next b-release or a nightly release (that would be cool)? I will need to change my classes now :) I will comment on/pursue these issues after I have used what's been done. Cheers Piyush On 8/9/06, Jerome Louvel [EMAIL PROTECTED] wrote: Hi Piyush, [..] Now we are talking taste here but I think Java packages aren't a very good example because some of them are there since jdk 1.0 and can't be refactored without breaking thousands of apps ..I am pretty sure that the Sun Java API gurus don't sleep easy at night :) Good argument, I buy that...and I do want to get some rest this night ;-) We are building something new here so we can be a little more adventurous. And my opinion is that having more packages isn't a sin packages are there to organize classes and help in avoiding to create cyclical dependencies .. I agree, it's a matter of finding the right balance between too many classes per packages and too many 'empty' packages. so a default package may be needed grouping all the default implementations .. or maybe another package hierarchy? I think I'd like to keep defaut/abstract implementations close to their interface. But I'm open to adapting the packages structure if needed. One thing I wanted to ask too was why do you have Enum implementing Interfaces? Is that something you saw being done someplace? Enums are Enums and by implementing interfaces you are trying to bridge the gap between Enum and Class that was created in 1.5 in order to make the distinction clear. My intent was to leverage the enumeration introduced in 1.5. So I started adding enums for methods, statuses, media types, etc. But then I realized that I couldn't enumerate all the potential media types, etc. So I thought about a way to allow usage of enums while preserving the extensibility. The only way I found was to introduce interfaces implemented by both enums and default classes. The problem is that I opened the Pandora box: if you get a media type, you can't switch it because you have to work from the interface... OK, I will refactor all this into single classes with static members for common values. That should greatly reduce the size of the data package. And I have seen some empty marker interfaces (Data and ControlData) and as per Joshua Bloch (and I totally agree) empty marker interfaces usually lead to problems later ... Good point, I was not initially sure if those REST concepts would need an equivalent Java artifact. For now, I've removed all of them and we'll see if/why we need them back down the road. Did you file a bug report on that or did you use an existing one? I have the opinion this isn't a wise move as how will I accomplish adding servers that aren't DefaultServers (That is what ServerMap does) to the components? You missed the fact that ServerMap extends WrapperMapString, Server and implements MapString, Server. So you can do put(name, myServer). In addition, I've changed the ServerMap's implementation to use directly the Factory instead of using the DefaultServer. Same thing for ClientMap. And the ServerMap from connector package creates an unnecessary dependency on WrapperMap in package data. If you were to remove all those collection wrappers to another package collections or util (if you want to take java's example) you remove these unencessary dependencies between your core packages... I don't see an issue in having a dependency between connector and data as data elements are naturally exchanged between components using connectors. For example, you need the Client.post(String uri, Representation input) method. However, I agree that we shouldn't have cyclical dependencies, like from data to connector or component. We'll also remove the dependency from connector to component later. In the end we should have this dependency tree: org.restlet.component +- org.restlet.connector +- org.restlet +- org.restlet.data Create a package org.restlet.spi (Service provider interface) and move Factory there. This package now can have dependency on org.restlet and org.component and honestly on all the rest of them too .. no problem :) Having just one Factory class, let's see if we can get rid
Re: error running b18 on Simple
Chris Winters wrote: Jerome Louvel wrote: Thanks for reporting this regression. It's fixed it in SVN. Make sure you fully refresh your local copy. Wow, lots of updates! And more API breaks :-) I'll plow through those and let you know how it goes. BTW, thanks for keeping up the relatively detailed notes the changelog. I know it's a PITA to do but much appreciated. Okay, that didn't take too long. Mostly just the MediaType/s collapsing (which is nice). Another thing I noticed is that using a base filename in the DirectoryHandler no longer works. My older code had: DirectoryHandler staticFiles = new DirectoryHandler( this, webUri, index ); which didn't pull up the 'index.html' page on a directory request. Changing it to: DirectoryHandler staticFiles = new DirectoryHandler( this, webUri, index.html ); worked fine. Do you think it's a good idea to have a set of possible files, similar to the Apache directive? I'll post a link to the silly sample app in a few minutes. Thanks for the updates! Chris -- Chris Winters ([EMAIL PROTECTED]) Lead Software Developer Vocollect Healthcare Systems CONFIDENTIAL, PRIVILEGED COMMUNICATION: This e-mail is private and intended for the addressee(s) only. It may contain privileged and/or confidential information. If you have received it in error you are not authorized to disseminate it in any manner; please delete it and any copies and reply to the sender that it was misdirected.
RE: error running b18 on Simple
Chris, [...] Another thing I noticed is that using a base filename in the DirectoryHandler no longer works. My older code had: DirectoryHandler staticFiles = new DirectoryHandler( this, webUri, index ); which didn't pull up the 'index.html' page on a directory request. Changing it to: DirectoryHandler staticFiles = new DirectoryHandler( this, webUri, index.html ); worked fine. Do you think it's a good idea to have a set of possible files, similar to the Apache directive? The issue is coming from the new negotiationEnabled flag which is turned off by default now. Just do directory.setNegotiationEnabled(true); to enable it. When exposing static files that were generated like Javadocs, there is no need for content negotiation based on file extensions. First, that slows things down a bit and then it creates side-effects with inner class names like Router.Mode because Mode is not a recognized extension, etc. As for having multiple index base names I'm not sure yet because that complexifies things for now. If you really need this you can always setup additional DirectoryHandlers for a specific trees of files. I'll post a link to the silly sample app in a few minutes. Thanks for the updates! I'm looking forward to playing with it :-) Best regards, Jerome
Restlet wiki (was: Resources and Representations)
FWIW, the Atlassian folks give free licenses to open source projects for both Jira and their wiki, Confluence. Take care, John
RE: (E)Tag: for resource or representation?
Hi Chris, [...] My reading of the HTTP/1.1 spec [...] says that an ETag (Entity Tag) is attached to a representation rather than a resource. [...] ...which says to me that I should generate the tag based on the content of a representation. Does this sound right? Absolutely, that's why the tag property is only available on the org.restlet.data.Representation interface. Also, the tag doesn't have to be necessarily generated based on the content of the representation. If not, you need a way to store this association because this tag has to be persistent across calls. FWIW: this is what I did in the sample app, but I didn't document why. Which means I forgot it within days... I saw you used the MD5 algorithm to generate the tag. This is cool, we should add that feature directly to the NRE/API: http://restlet.tigris.org/issues/show_bug.cgi?id=149 Note that there is also a Content-MD5 header that seems to overlap with you usage of tags. I'm not sure why we have both in the spec: http://www.rfcsearch.org/rfcview/RFC/2616.html#14.15 Best regards, Jerome
Re: silly sample app available
Piyush Purang wrote: Where is it available? Did I miss a few emails here? It was in the first message in the thread: Location: http://www.cwinters.com/raw/RestSampleBook.zip Chris -- Chris Winters ([EMAIL PROTECTED]) Lead Software Developer Vocollect Healthcare Systems CONFIDENTIAL, PRIVILEGED COMMUNICATION: This e-mail is private and intended for the addressee(s) only. It may contain privileged and/or confidential information. If you have received it in error you are not authorized to disseminate it in any manner; please delete it and any copies and reply to the sender that it was misdirected.
