Re: PROPOSAL: Extensions to XMIReader and XMIWriter interfaces

Hi Brian,

Brian Smith wrote:
> Yes, you are right, my idea doesn't work well when multiple clients are 
> sharing the same XMIReader/XMIWriter. But at the same time, I don't 
> think it makes sense to keep adding methods to XMIWriter/XMIReader that 
> add an extra argument for each possible customization. For example, in 
> the (near?) future you will probably want to be able to handle 
> XMI.extension elements and also be able to deal with XMI.header 
> information. And I think you will end up with combinitorial growth in 
> the number of methods in these interfaces if the plug-in functionality 
> is done by adding parameters to the read/write methods in these interfaces.

You are right. We need to find a clean solution for this. Any ideas are 
welcome...
I think that most common situations can be solved using lookup (default 
HRefResolver, XMIReferenceProvider, etc.). For all other things, we may 
introduce one additional parameter of some more generic type that can be 
defined in the API and XMIReferenceProvider, XMIHeaderProvider, etc. may 
be interfaces inheriting from this generic type. One may then implement 
the interfaces they wish in a class and pass this implementation to the 
write method (similar mechanism would work for the XMIReader). The 
method with the additional parameter would be called only rarely, where 
the default "lookup" mechanism is not sufficient.

>>> This way, we can set the default resolver at application start up 
>>> time, and thus isolate direct dependencies on MDR-specific methods to 
>>> a smaller part of our code.
>>
>>
>> Do you think the lookup is appropriate? AFAIK there is no way of 
>> redefining lookup entries in your application if MDR library already 
>> adds the default implementation of HRefResolver.
> 
> 
> I am wondering if Lookup is appropriate for XMIWriter and XMIReader. 
> Perhaps XMIWriter and XMIReader instances shouldn't be shared?

I thought that lookup is the best way of keeping the XMIReader/Writer as 
much compliant with the JMI as we can. Requiring users to know different 
constructors and class names of different implementations of 
XMIReader/Writer makes them non-switchable and the XmiReader and 
XmiWriter interfaces become nearly useless (as for each different 
implementation of these interfaces you need to change your source code 
anyway).
Another solution could be to use lookup for finding a "factory" for the 
implementations of these interfaces and be able to create several 
instances of them. I am not sure if this would be a better approach.

> 
>  > Should we then remove
> 
>> all meta-inf lookup entries from the MDR libraries themselves and move 
>> them to the applications that use MDR? (this would solve also the 
>> issue that we currently have with dev builds of NB - see the e-mail I 
>> sent out this morning).
> 
> 
> I don't really know how to solve this lookup issue, but it seems that it 
> will is already being resolved in a way that doesn't require the 
> removal.

You are right. It will be solved in Monday's build, so it is not a 
problem any more.
Martin