Am 14.04.2021 um 00:09 schrieb Oliver Lietz:
I don't get the eventing example. Resources are a substantial part of Sling
and defined in Sling API. Sling API bundle already contains several utils
around Resource (and HTTP Request/Response and Scripting). Resource and
Resource Type are very general and not necessarily bound to Scripting.
Eventing is optional and a complete different story.
Fair enough, eventing wasn't maybe the best example.
Again, I see a value using ResourceType when dealing with Resources in Sling
not related to Scripting.
While I agree that resource and resource type are the core concepts of
Sling and beling in the API, the discussed ResourceType class still does
not look like that to me. I'm still missing a use case for this.
If the intended use is Scripting only why not renaming it to ScriptType in
Scripting SPI and adding a copy as ResourceType to Sling (Resource) API...?
:) I guess the last thing we want is code duplication.
What is the real drawback of having ResourceType in Sling API?
Avoiding unnecessary dependencies, coherent apis and avoiding that they
just get a dumping place for useful sounding things. I'm not saying that
this is the case here, but still I fail to see why this needs to be part
of Sling API.
For example, this class introduces a dependency on the OSGi Version
class as part of the API - so users of the Sling API are then required
to also have the OSGi framework api - which I think should be avoided.
So by putting this into the Sling API all users are punished to have
this extra dependency. And embedding that class will sooner or later
result in problems (we had a similar situation in the feature model -
where the dependency makes sense as the feature model is about OSGi).
How about we go with a compromise? We move that class to a separate
package but leave it in the current bundle? If it turns out to be useful
for each and every Sling developer, we can move the package to Sling API
- without being incompatible.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
