[
https://issues.apache.org/jira/browse/OLINGO-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14291894#comment-14291894
]
Michael Bolz commented on OLINGO-482:
-------------------------------------
Hi [~rareddy],
bq. In my experience, community typically more vocal about raising a bug issue
than readily engage in debate our architecture decisions. I do wish other
members of community stepped up on this issue more to get wider perspective.
So, I doubt there will be much discussion. If we can't come to consensus (I
already pushed my development 2 months for this feature), may be we can provide
an extension in the ODataHandler to delegate processing to another interface,
where I can write my own layering outside of Olingo library. Once we get up to
(4.0.0-beta-02) or CR, it will be too late to change interfaces of this
magnitude and I know that is sure way to anger of more community members, which
I do not want for us.
I'am really sorry that you pushed your development and I agree with you and
also wished that other developers comment their point of view about this.
Hence, my first thought was that a release of {{4.0.0-beta-02}} would make it
easier for community to use the lib and give feedback on this release (and
processor interfaces).
Could you agree that we go forward with the release with current processor
design and additionally announce a discussion (on mailing list) about the
processor interfaces as well as that the processor interfaces may be changed to
{{4.0.0-beta-03}} which then could be provided just e.g. a month after this
release?
This way the community will be informed about a potential upcoming API change
and then will not be in anger. What do you think about this?
Kind regards,
Michael
PS: Tomorrow I will have the time to take a deeper look into your comment and
API suggestion. But after a first short look I can say that some parts really
look interesting.
In addition I'am confident that we find a good solution. Or we really add an
extension point like an {{ExtensionProcessor}} which can be registered at the
{{ODataHandler}} to which each call then will be delegated for processing ;o)
> Refactoring of {{Processor}} interfaces
> ---------------------------------------
>
> Key: OLINGO-482
> URL: https://issues.apache.org/jira/browse/OLINGO-482
> Project: Olingo
> Issue Type: Improvement
> Components: odata4-server
> Affects Versions: V4 4.0.0-beta-01
> Reporter: Michael Bolz
> Assignee: Michael Bolz
> Attachments: processor.png, request_model.png, response_model.png
>
>
> h2. Idea
> During the introduction of the {{RepresentationType}} a discussion has
> started about re-factoring of the {{Processor}} interfaces.
> The new idea is to create an own {{*Processor}} interface for each
> {{RepresentationType}} which then has the according HTTP methods (in form of
> read/write/..).
> As a result we don’t have explicit {{ProcedureProcessor}} because during the
> dispatching the {{ReturnType}} of an e.g. Function is evaluated and the call
> is than processed by the according e.g. {{EntityProcessor}} or
> {{EntitySetProcessor}} or {{SomeOtherProcessor}}.
> For the {{ProcessorInterfaces}} the return type ({{RepresentationType}}) and
> its content is leading (and NOT the format). According to this each return
> type (RepresentationType) results in an own {{*Processor}} Interface with
> methods for the possible HTTP Requests (see Mapping HTTP Request -> Processor
> Method). For some exception the return types should be added as method to an
> existing {{Processor}} Interface.
> As example the {{readPrimitiveAsValue(..)}} method should be added at
> {{EntityProcessor}}. On the other side for the {{countXX(...)}} methods an
> own {{Processor}} should be created because the result is not the content of
> the entity (in a different format).
> h2. Mapping HTTP Request -> Processor Methode
> * HTTP GET -> read_XX(...)
> * HTTP POST -> create_XX(...)
> * HTTP PUT -> update_XX(...)
> ** HTTP PATCH -> update_XX(...)
> * HTTP DELETE -> delete_XX(...)
> h2. Processor Interfaces
> * ServiceDocument - R
> * Metadata - R
> * Error - P rocess
> * Batch - P rocess
> * Entity - CRUD
> * EntityCollection - R
> * Primitive - RUD
> * PrimitiveCollection - RUD
> * Complex - RUD
> * ComplexCollection - RUD
> * Count Processor als
> ** Count - R
> oder
> ** CountEntityCollection - R
> ** CountPrimitiveCollection - R
> ** CountComplexCollection - R
> * Media - CRUD => Create Media at {{EntityProcessor}}
> * -Binary - CRUD-
> * -Value - CRUD- => Added as {{readPrimitiveAsValue(...)}} Methode at the
> {{PrimitiveTypeProcessor}}
> * Reference - CRUD
> * ReferenceCollection - RU\[?\]
> * Difference (Delte/Tombstone) - R
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
