Write a proposal on how should file recognition look like future,
discuss it and implement it. The goal is to split the file recognition
in the common optimalizable part and the actual sub-recognitions
which would (in most cases) will then be just creating DOs over FOs.
See original message at
Created a central proposal page at
Write a proposal on how should loaders storage look like in the future. Loaders are the last part of
system which can't be declared in module XML layer, new storage should support:
- declarative way of definition
- save-through functionality, it should automaticaly sync changes between disk and memory (see issue
*** Issue 13043 has been marked as a duplicate of this issue. ***
Any configurable properties should be stored in normal .settings files
Note that for a recent optimization in loader pool storage, I
considered saving loaders in Loaders/*.settings, but decided that
there might be too much overhead to read all those additional XML
files. Otherwise I would have; would be much simpler and more
consistent than the current loaders.ser system. Anyway if
org.openide.loaders.DataLoader goes away then the point may be moot.
Changed owner David S. -> David K.
URL points to the most recent proposal.
Changing TM to FUTURE for several DataSystem enhancements. The DS are planned
for rewrite and so it does not make sense to invest time into these
enhancements. If you think the issue is important and should be fixed for 4.0
then feel free to let me know. I'm open to change the plan.
I'll speed the recognition for 6.5, however probably as part of other, fresh issue.