Re: [xml-dev] Re: XML Entity Catalogue

Petr Kuzel wrote:
>>>It's faster to use private namespace.
>>
>>Not sure what you mean.
> 
> Private FolderLookup performs better than Lookup.getDefault().

Are you sure? Lookup.getDefault is cached between sessions (its 
structure that is) so it should be reasonably fast. That is not true of 
a private FolderLookup. Anyway the cost is only when a catalog is first 
used, not every time.

>>Lots of stuff in Options is project-sensitive. That is why there is the
>>magic "<<<" column that shows you which things are project-sensitive and
>>lets you change that status on the fly.
> 
> But in case of XML catalogs user cannot change it, module
> provided catalogs are global, user's catalogs are project
> specifics.

That's fine. If you register a catalog in a layer, by default it will be 
global (appear in every project). User catalogs are by default 
project-specific. All this should be handled automatically by the 
project and layer infrastructure; the XML Catalog module should not need 
to do anything special, except put layer=project on the 
Services/XMLCatalog/ (empty) folder in its layer.

> (in fact requirement was that user must not be able to customize it).

Strange.

> I choose the simplest and backward compatible implementation
> I was aware of.

Of course the backward compatibility issue is real - when the system 
option dies, you will need to provide an automated upgrade to the new 
storage.

>>Sorry, missed this fact. Of course that is not an argument for using a
>>system option - it is just not an argument for not using one. (SFS
>>folders can be marked as being project-specific for new files: Mount/ is
>>an example.)
> 
> Current implementation bets on fact that only one project is
> active. Folder marking has the same problem. Both solutions
> are from my point point view equally 'dirty'.

True, but by using the simpler design of defining one folder to hold 
catalogs and leaving the storage up to core+projects, it should be 
easier to take advantage of multiple-project support in the future. I hope.

Well, actually in 4.0 Projects you will probably need to grab the 
relevant project from somewhere (not sure where), and merge in its JNDI 
context or whatever - there will be no "active project" or set of them, 
so you need to explicitly put together what you need. Same basic idea 
though.

>>4. Permit some things to be project-specific and others to be global,
>>and the two merged together.
> 
> There is rather big problem: merging ordered items. User cannot
> order global and project items to each other.

Why not? Works for filesystem mounts.

>>5. See modifications to module-provided catalogs and revert them.
> 
> Some module-provided catalogs should be unmodifiable. Module
> should decide if it provides fixed catalog of a default catalog
> (content).

Sure, but that can be controlled by e.g. use of .settings vs. .instance, 
at the module's discretion.

>>All these things are supported using the current Services API. Hopefully
>>they will be even easier using the Registry API and new Projects.
> 
> I hope that I'll be able to leverage them easily achieveing user's
> settings backward compatibility.

Well, compatibility will be annoying no matter what, because you will 
probably need to (1) be able to read the old SystemOption .settings file 
- meaning you may need old @deprecated classes around just to 
deserialize - (2) when it is present, automatically delete it and create 
matching individual entries in the proper folder (or JNDI context, or 
Registry context, or whatever it is).

-Jesse

-- 
Jesse Glick <mailto:[email protected]> x22801
NetBeans, Open APIs  <http://www.netbeans.org/>