Community
Participate
Working Groups
This is related to 144950 but is a bit different. 144950 talks about enhancing EMF to support large datasets, etc. This enhancement suggests an alternative to EMF (the model, the api, etc.) for collections/views with large data requirements. Profiling views would be a good first candidate for consuming such an alternative component/api. Such an approach may allow a simpler solution than one that requires an EMF veneer. To make such a model work, when a data import or data stream is created, it would need to choose either the legacy EMF model or the new model based on the data type and views supported by the data type. Only new views (non-EMF based) could use new data. For example, existing views (e.g., thread, execution stats, etc) would be split into deprecated versions using the EMF model and new views (e.g., thread, execution stats, etc.) that are ported to use the new model. Presumably only the new versions of these views would be considered for further view enhancement. For consumers that depend on underlying EMF model, the data would need to be loaded into EMF and would thus not be able to take advantage of this enhancement. If such an approach is successful, in TPTP 5, the underlying EMF model could be considered for removal as an API for profiling data.
I meant to tag this as enhancement request
Thanks for bringing this to the front again Chris. One thing we need to continue to keep clear and separate is that EMF as a framework provides multiple things. Some we have learned we don't want, and some we do. Although XML serialization has been good to prove out the overall framework, it is not the scalable solution we expected extending consumers to use. However the community wants TPTP to do this directly so we need an alternate persistence impl.. All the various initially generated code for UI notification etc. is great free code that can be error prone to hand write, so this has been a plus. EMF models tend to be fully in memory, particularly when backed by XML persistence. So using one model as the UI model and the persistence model is something we got for free from EMF but don't really want, and we have been making progress to isolate the current EMF to be the UI model only. A large part of the effort however is that the UI needs to be query orientated versus assuming all data is in memory. This is the change we have focused on to date. I think you are proposing that "loaders" have pluggable targets (storage systems) and that the UI run queries over these targets. This actually has been a plug point for the loaders all along but not exploited. The proposal to exploit this and use an alternate storage system is written in the TPTP wiki, and perhaps we can renew the objectives and design discussions there.
the wiki entry I mentioned http://wiki.eclipse.org/TPTP_DMS
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html).
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
