91665 DataLoaders - API and UI review Reviewers: - Jan Pokorsky - Jiri Skrivanek - Jesse Glick - Andrei Badea Attendees: - Petr Pisl - Radek Matous - Antonin Nebuzelsky - Ondrej Langr Motivation * Performance - speed, scalability * See http://wiki.netbeans.org/FitnessAgainstForgetfulness The essence: -> Split linear data loader recognition to a set of sublists of loaders defined by mime type. Introduce new registration. And new UI in Options. * Keep backward compatibility - old loaders * New UI - only for new results Notes: Incompatible change for those depending on order of loaders (e.g. to be before xml or java) - in the old registration. * Can we have the old ones (manifest type) at the beginning of the recognition chain (before mime types)? * Needed for external modules having special registrations - typically for xml loaders. * Performance impact - but probaly fine if we convert all standard IDE loaders. We have about 60-70 loaders in repo. * TCR - Compatibility is important: Have the old (manifest-registered) loaders at the beginning of the recognition chain (before mime types). * TCA - someone should change it all... also because UI * BTW also need to fix api support to generate the new registration. [JG01] vs [I01] - Use numeric positioning instead of Install-Before/After... * Agreed, Ivan not present, can't defend. [JG02] - UI in Options: Not clear how this is going to work for non-trivial cases. Assuming list of file extensions maps to mime type directly. * TCR: All mime resolvers mapping that are plain extension-based. E.g. ant has one - for 'ant', and couple of more complicated associations that need not be shown. Complicated cases hidden from GUI. (So e.g. xml associations.) When the user wants to register their own file extension to a mime type/loader association, all mime types must be available to choose from. * TCR: User customization will get a new resolver created when needed. No edits of original ones (e.g. if user adding a new extension for ant). And positioned as first in the chain of loaders. * TCR: In UI "Opens With" is misleading - listing possible loaders - remove it. * TCR: "File Extensins and Patterns" - remove pattern - resolvers only work with extensions. Don't use *.ext, only list extensions. * TCR: Context menu for unrecognized files - have special "Open As" action, "Open" should just open in text editor - so doubleclick always work immediately. * TCA: Investigate how easy should it be to screw up the IDE - e.g. by registering something strange for java extension? We should avoid happening that by accident (not noticing). Compare to other apps - e.g. Firefox. * Remove localized labels from mime resolvers? Not useful, garbage. Plus change API support not to generate them. But probably not needed. TCR: Fix the API support. [JG03] - Would be nice if DataLoader did not extend SharedClassObject. We could have auto-created loaders based on registration. * New interface DataObject.Factory... looks nice, need to check it works. * TCA [JG04] Ensure that so long as MIMEResolver's are correctly registered, DataObject recognition works identically inside unit tests as in the full platform. * Jarda: Don't know how to implement... * Jesse: Because we have so many problems due to this inconsistency. Should work in unit tetsts only with loaders and filesystems on classpath. But not necessarily part of this review. * TCA: Provide infrastructure so all loaders placed in layer files should work in unit tests if utils, filesystem and loaders are on classpath - as long as given mime type is resolved. [MP1] - Inconsistency in the registration scheme - in complex cases where there is no 1:1 mapping between mime type and loaders the actions registered next to the loader may actually not be used... * refused, edge case Problem of text/ant+xml? Currently we have special handling for XML mimetypes... * TCR: Agreed to remove it. Plan * Integrate befor M1. * Fix all loaders in big IDE. * All teams need to check and verify. * UI later during M2. Voting * 4 yes - approved * Will do next week without UI changes (later).