[
https://issues.apache.org/jira/browse/IMAGING-159?focusedWorklogId=678434&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-678434
]
ASF GitHub Bot logged work on IMAGING-159:
------------------------------------------
Author: ASF GitHub Bot
Created on: 08/Nov/21 12:04
Start Date: 08/Nov/21 12:04
Worklog Time Spent: 10m
Work Description: darkma773r commented on pull request #116:
URL: https://github.com/apache/commons-imaging/pull/116#issuecomment-963083902
@kinow
I agree with @gwlucastrig, that we should try to keep the API simple. It
might be helpful to take a step back and enumerate all of the use cases the API
should cover and then decide how they should be handled. Below is what I see
(from my limited perspective) as the main use cases. Please add any I've missed.
1. The user wants to read/write an image and does not know or care about the
format.
2. The user wants to read/write an image and does not know the format but
wants to apply some format-specific parameters if applicable.
3. The user wants to read/write an image in a specific format.
For the first use case, I think @gwlucastrig's idea of removing
format-specific parameters from `Imaging` applies. The caller would use the
`Imaging` class and then either pass no parameters or pass a very basic
`ImagingParameters` instance.
For the second use case, I think the responsibility for creating the correct
parameters object could fall to the user. For example, the user would use
`Imaging.guessFormat()` to get the format and then use the format-specific
parser directly to access additional features. The `Imaging` class would not
play a role after the initial determination of the format.
For the third use case, I think users should use the format-specific parser
directly.
So, what I'm picturing basically boils down to this:
- Do you want to read/write images and only care about the most basic of
image parameters? Great! Use `Imaging`.
- Do you want to read/write images in a specific format and access low-level
format features? Cool. Use the parser for the format.
This approach would remove some of the design headaches we keep running into
with `Imaging`, where we're trying to allow access to format-specific features
from generic code. If we can agree on how the API should address these use
cases then we can move on to deciding how to make the API readable and
user-friendly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 678434)
Time Spent: 14h 40m (was: 14.5h)
> There should be a Parameters class
> ----------------------------------
>
> Key: IMAGING-159
> URL: https://issues.apache.org/jira/browse/IMAGING-159
> Project: Commons Imaging
> Issue Type: Improvement
> Components: imaging.*
> Affects Versions: 1.0-alpha2
> Reporter: Benedikt Ritter
> Assignee: Bruno P. Kinoshita
> Priority: Major
> Labels: github
> Fix For: 1.0-alpha3
>
> Time Spent: 14h 40m
> Remaining Estimate: 0h
>
> Currently options for image I/O are defined as Maps. The leads to the problem
> that our code has to validate parameter types when they are used:
> {code:java}
> final Object value = params.get(PARAM_KEY_COMPRESSION);
> if (value != null) {
> if (!(value instanceof Number)) {
> throw new ImageWriteException(
> "Invalid compression parameter, must be numeric: "
> + value);
> }
> compression = ((Number) value).intValue();
> }
> {code}
> This can be simplified if we define a Parameters class that provides
> additional methods like {{public int getInt(String key)}}. The implementation
> could then look up the value from the map through an exception if it is null
> or not a number.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
