Hi Florian, will do, I'll hopefully have a patch for you to review next week.
c. 2013/5/10 Florian Müller <[email protected]> > Hi Carlo, > > Please go ahead and make a proposal. Submit a patch that sketches your > ideas. It doesn't have to be complete and running. > It's easier to talk about something concrete rather than discussing about > generic topics. > > - Florian > > > > Hi Florian, >> >> it's not my intent to start a flame war, and we can continue offline if >> you >> want. To the interest of the list, I'll just write here some of the >> reasons >> behind my previous comment, and wait until I have some patch ready to >> prove >> my points before bothering you guys again with my ramblings. >> >> I understand your remark on the spec compliance, and that interop is at >> stake when you allow the protocol details to be modified. BUT... >> >> - There's much more to HTTP than what CMIS specifies, and Chemistry is >> currently in charge of handling the transport protocol on top of which >> CMIS >> expresses itself. >> >> - No extensibility means that backporting of fixes might be a no-go. For >> example, if I now upgrade Chemistry to the latest trunk my code doesn't >> compile anymore. Subclassing would be the best way to integrate your >> changes in the version I use, but that's not available to me. >> >> - The CMIS spec is (hopefully!) not fixed and will evolve with time. OO >> could help greatly e.g. to support different versions of the protocol with >> a single serve instance, which is painful to implement cleanly following >> the current code approach. >> >> - Spec extensions are not evil per se. While they might indeed break >> interoperability, they're also a way to open the protocol itself to >> experiments and eventually drive a community based evolution of it. >> >> - Interop is not always the top priority. CMIS and Chemistry provide a lot >> of value OOTB, and I don't see why proprietary extensions should be denied >> by principle. Why shouldn't I have the possibility to write a custom >> extension to improve e.g. content delivery capabilities >> (getContentStreamByPath, anyone?), while still retaining full protocol >> compliance for B2B data exchange? >> >> If you made it to here, a big thank you for your patience. >> >> Hope this helps, >> c. >> >> >> >> >> 2013/5/8 Florian Müller <[email protected]> >> >> Hi Carlo, >>> >>> This code is not meant to be extensible. The CMIS standard is fixed. >>> There >>> will be no additional services or operations. Also, the semantics of the >>> parameters will not change or have to be changed. Any extensions would >>> bypass the specification, which would be a pain for clients and doesn't >>> help interoperability. >>> All methods that handle requests are stateless, isolated pieces of code. >>> OO doesn't help here. And the alternative to reflections would be a 120 >>> lines if-statement. I can't see the advantage of that. >>> >>> Also, this part is considered internal code and may change at any time. >>> OpenCMIS provides a lot of extensibility on the client side and keeping >>> the >>> interfaces compatible does hurt sometimes. I don't see a real use case to >>> have that pain also on the server side. If there is something missing or >>> wrong, we usually fix it pretty quick - as you have seen. >>> >>> Having said that, if you have a great idea how to refactor that code, >>> feel >>> free to provide a patch. >>> >>> >>> - Florian >>> >>> >>> Am Mittwoch, den 08.05.2013, 16:05 +0200 schrieb Carlo Sciolla < >>> [email protected]>: >>> >>> Hi Florian, >>>> >>>> thanks for your quick commit, I will experiment a bit with it and let >>>> you >>>> know what comes out of it. I do already have some initial comments >>>> anyway: >>>> >>>> - I see you only addressed the browser bindings implementation. While I >>>> can >>>> see the reason behind it, I think it won't hurt to also apply a similar >>>> logic to the AtomPub binding >>>> >>>> - as I'm stuck with v0.6.0, I'm looking into ways to backport or >>>> integrate >>>> your code in my app. The current logic for method dispatch in AtomPub >>>> goes >>>> against extensibility (and some object oriented design principles, IMO) >>>> and >>>> while for the time being I can work around it, would you guys consider >>>> refactoring the dispatch logic to make use of non-final classes / no >>>> reflection / public constructors? >>>> >>>> Thanks, >>>> c. >>>> >>>> >>>> 2013/5/8 Florian Müller <[email protected]> >>>> >>>> Hi Carlo, >>>> >>>>> >>>>> I've added some new code. There are now three interfaces that let you >>>>> control the server headers. >>>>> The ContentStream object that is returned by getContentStream() must >>>>> implement the interface(s) to trigger the behavior: >>>>> >>>>> ContentLengthContentStream - Sets the Content-Length header and turns >>>>> chunking off. >>>>> >>>>> LastModifiedContentStream - Sets the Last-Modified header and respects >>>>> the >>>>> If-Modified-Since header. >>>>> >>>>> CacheHeaderContentStream - Sets the Cache-Control header, the Expires >>>>> header, and the ETag header and respects the If-None-Match header. >>>>> >>>>> >>>>> Please let me know if that works for you. >>>>> >>>>> >>>>> - Florian >>>>> >>>>> >>>>> Hi there, sorry for the late reply. >>>>> >>>>> >>>>>> 2013/5/7 Florian Müller <[email protected]> >>>>>> >>>>>> That is surprising. Chunked encoding isn't really exotic. >>>>>> >>>>>> >>>>>>> Definitely, but browsers are always there to remind us that world >>>>>>> class >>>>>>> >>>>>>> standards are nothing different from regional social conventions, >>>>>> are >>>>>> they? >>>>>> >>>>>> >>>>>> Could you please open an Improvement issue and add a few details. >>>>>> I'll >>>>>> >>>>>> look into it. >>>>>>> >>>>>>> Thanks, here it is >>>>>>> <https://issues.apache.org/******<https://issues.apache.org/****> >>>>>>> >>>>>>> jira/browse/CMIS-655<https://**issues.apache.org/**jira/** >>>>>>> browse/CMIS-655 <https://issues.apache.org/**jira/browse/CMIS-655>> >>>>>>> >>>>>>> <https://**issues.apache.org/**jira/browse/**CMIS-655<http://issues.apache.org/jira/browse/**CMIS-655> >>>>>>> <https:/**/issues.apache.org/jira/**browse/CMIS-655<https://issues.apache.org/jira/browse/CMIS-655> >>>>>>> > >>>>>>> > >>>>>>> >>>>>>> >. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> > -- Carlo Sciolla --==(A)==-- Linux User #372086 My personal blog: http://www.skuro.tk Follow me on twitter: http://twitter.com/skuro <http://twitter.com/skuro>Fork me on Github: http://github.com/skuro <http://github.com/skuro>My LinkedIn profile: http://nl.linkedin.com/in/carlosciolla --==(A)==-- Product Lead at Backbase - Next Generation Portal Software for Financials & Large Enterprises (http://www.backbase.com)
