Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Customizable analysis #164

Conversation

bhufmann
Copy link
Contributor

@bhufmann bhufmann commented Oct 1, 2024

name = name == null ? defaultValues.getName() : name;
String description = config.getDescription();
description = description == null ? defaultValues.getDescription() : description;
return builder.setId(config.getId())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems a bit odd that we create a TmfConfiguration with id, name, description that can come from the json string and then the TmfConfiguration also contains the json string, so these values are duplicated inside the TmfConfiguration object.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this statement for name and description. The ID is generated to remove burden of end-user to create a unique ID. We use this class to serialize a TmfConfiguration that has generated ID. When deserializing the configuration, we read the ID back, no need for regeneration.

* @return list of the available providers for this trace / experiment
* @since 9.5
*/
public synchronized @NonNull List<IDataProviderDescriptor> getAvailableProviders(ITmfTrace trace, String configId, String... ids) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For supporting per base DataProvider conifgurations We would need a getAvailableProviders(ITmfTrace trace, String... ids) to return all DataProviders which contain the (factoryId == baseDataProvider ID).
That, or DataProvider Descriptor object would need to be a tree of descriptor strings.

Copy link
Contributor Author

@bhufmann bhufmann Oct 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could be useful. It would return all derived data providers for all configurations for the base data provider.

*
* @since 9.5
*/
default String getJsonParameters() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* If the creation of the configuration fails
* @since 9.5
*/
default ITmfConfiguration create(String parameters) throws TmfConfigurationException {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

throw new TmfConfigurationException("Can't convert json string to Map to update configuration", e); //$NON-NLS-1$
}
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* if an error occurs
*/
// List<IDataProviderDescriptor> createDataProviderDescriptors(String typeId, ITmfTrace trace, Map<String, Object> parameters) throws TmfConfigurationException;
List<IDataProviderDescriptor> createDataProviderDescriptors(String typeId, ITmfTrace trace, String jsonParameters) throws TmfConfigurationException;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

* if an error occurs
*/
void removeDataProviderDescriptor(ITmfTrace trace, IDataProviderDescriptor descriptor) throws TmfConfigurationException;
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this interface needs also a method to remove the config which will then remove the data providers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class might not be needed and json serialization and deserialization to disk can be in the TmfConfiguration class after removing the jsonParameter string support, as discussed here:

eclipse-tracecompass-incubator/org.eclipse.tracecompass.incubator#88 (comment)

@abhinava-ericsson @PatrickTasse

name = name == null ? defaultValues.getName() : name;
String description = config.getDescription();
description = description == null ? defaultValues.getDescription() : description;
return builder.setId(config.getId())
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this statement for name and description. The ID is generated to remove burden of end-user to create a unique ID. We use this class to serialize a TmfConfiguration that has generated ID. When deserializing the configuration, we read the ID back, no need for regeneration.

* @since 9.5
*/
default @Nullable String getParentId() {
return null;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I opted to only have the parentId in the descriptor to create an hierarchy and not having also a getChildren() method. This is easier to implement at the moment, but we can opt to implement it at a later time if we realize it's to iterating through the list of descriptors to find the parent - children hierarchy.

If we opt to have the getChildren() I suggest to implement later and not in the initial version of the fullstack support of data provider configurations.

FYI @PatrickTasse @abhinava-ericsson

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds right. Currently, DataProviderManager maintains a list of all Data Providers, and we don't have nesting of derived data providers. So, base data providers don't really need to be aware of their children.
As you said, after full-stack implementation, if we see any performance or simplicity benefit by adding getChildren(), we can implement it.

* data provider, or null if not applicable
* @since 9.5
*/
default @Nullable ITmfConfiguration getCreationConfiguration() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like the name of the method. Any suggestions for a better name? @PatrickTasse @abhinava-ericsson

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just getConfiguration() is fine till we don't allow modification of an existing configuration. Later, if we do allow that, we can differentiate between getConfiguration() and getInitialConfiguration().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getConfiguration() sounds like there can be only one. We might (I don't have use case yet) some other configuration, that does something else than creating a data provider. That's why I used creationConfiguration, but I don't like it. Maybe for now we call it getConfiguration() as you suggested and that's the configuration that was used for creation. If we in the future support another configuration we can find a name for the new type configuration.

@@ -273,6 +273,37 @@ public interface ITmfTrace extends ITmfEventProvider {
*/
@NonNull Iterable<@NonNull IAnalysisModule> getAnalysisModules();


Copy link
Contributor Author

@bhufmann bhufmann Oct 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@PatrickTasse @abhinava-ericsson

This API needs explanation. In Trace Compass analysis modules are managed by the TmfAnalysisFramework through IAnalysisModuleSource extension. The ITmfTrace has a method getAnalysisModules() and that collection has only analysis modules that are configured through the analysis framework when opening a trace TmfTraceOpenSignal() processed which triggers the method executeAnalysis(). This then call TmfAnalysisManager.getAnalysisModules() which will then instantiate the modules and store in the trace object

Many data provider factories often use TmfTraceUtils.getAnalysisModulesOfClass(trace, IFlameChartProvider.class); which call ITmfTrace.getAnalysisModules(). So, if an analysis module is not know by the analysis framework, then analysis module is not instantiated and not return by the trace.

These 2 methods will by-pass the analysis framework and custom analysis modules can be added and removed. This is needed for the custom analysis implementation.

Please note that the analysis framework, reads some global configuration to instantiate so-called IAnalysisModuleHelpers which globally available and assigned to applicable traces. These helpers are used to instantiate the actual analysis module and then configure it with parameters provided by the extension point or xml definition.

One thing to remember, if we would like to use the analysis framework for custom analysis, which is doable and I prototyped, there needs to global storage of configuration files (e.g. json), a manager class that can add and remove such configurations as well as assign it to a trace. However, the design of customizable analysis through data providers (factories) doesn't the provision for having such manager class and the required server endpoint.

* @return true if it was successful or false if invalid config (TODO should we through exception?)
* @since 9.5
*/
default boolean setConfiguration(ITmfConfiguration configuration) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This use needed to be able to add the configuration IDataProviderDescriptors for derived data providers. This is not used by the analysis framework, and hence doesn't have equivalent methods in IAnalysisModuleHelper.

@PatrickTasse @abhinava-ericsson

* @return true if it was successful or false if invalid config (TODO should we through exception?)
* @since 9.5
*/
default @Nullable ITmfConfiguration getConfiguration() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This use needed to be able to add the configuration IDataProviderDescriptors for derived data providers. This is not used by the analysis framework.

* @return the configuration root path
* @since 9.5
*/
default @Nullable String getConfigurationRoot() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be removed. It's an artifact from a protoype that uses the anlaysis framework.

@bhufmann bhufmann force-pushed the json-schema-json-if-factory-fixes branch from d013347 to 140ffae Compare October 28, 2024 12:37
@bhufmann bhufmann closed this Oct 28, 2024
@bhufmann bhufmann force-pushed the json-schema-json-if-factory-fixes branch from 140ffae to 751b02c Compare October 28, 2024 17:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants