chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <f...@apache.org>
Subject Re: Chunked transfer encoding
Date Fri, 10 May 2013 13:30:09 GMT
 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 <fmui@apache.org>
>
>> 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 <
>> carlo.sciolla@gmail.com>:
>>
>>> 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 <fmui@apache.org>
>>>
>>>  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 <fmui@apache.org>
>>>>>
>>>>>  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/****
>>>>>> 
>>>>>> 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>
>>>>>> >
>>>>>>
>>>>> >.
>>>>>
>>>>>
>>>>
>>>>
>>


Mime
View raw message