Home » Modeling » EMF » [EMF] Question related with URIConverters and URIHandler (again)
|
| Re: [EMF] Question related with URIConverters and URIHandler (again) [message #428103 is a reply to message #428102] |
Tue, 10 March 2009 18:52   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Víctor,
Comments below.
Víctor Roldán Betancort wrote:
> Hi Ed,
>
> may I ask you, is there a reason why there doesn't exist an extension
> point for contributing new URIHandlers to ExtensibleURIConverterImpl?
Yes, you may ask. :-P
There is a danger in supporting such a thing because the handlers are
consulted in sequence and the longer that sequence, the more the
overhead. Suppose 100 components all decided their handler is really
cool and should be available for everyone, well at least as far as their
use of EMF is concerned.
>
> we have the following piece of code:
>
> return resourceSet.getURIConverter().exists(resourceURI, null);
>
> where we want to determine if a resource is in fact "serialized".
?
>
> This resource could be a CDOResource. I believe the only way we can get
> the correct behaviour of "exist()" is contributing a new URIHandler to
> the URIConverter that understands CDO URIs. We could do that
> programmatically adding such URIHandler, but we would like to avoid
> dependencies in our code with CDO bundles.
So you could define an extension point. :-P Don't your models already
depend on CDOEObjectImpl?
>
> I must say I haven't dig very deep in this issue, but at first sight it
> looks like the kind of thing that would be nicely solved through
> extension points, the same way Resource.Factory are contributed to the
> framework.
I certainly did consider it, but given how appealing it would be for one
client to inject overhead into all EMF applications it seemed not so good.
>
> Another solution would be creating our own URIConverter that extends
> ExtensibleURIConverterImpl and allows contribution through extension
> point.
>
> Yet another solution could be integrating CDO with EFS and using
> EFSHandler...
I was going to suggest that. That probably has some other significant
benefits as well...
>
> still defining an Ext. Point for seems to me the most straight
Yep. It wasn't just something I overlooked though but rather something
I deliberately did not do.
>
> I think I recall discussing related issues in other posts...
>
> Thanks in advance :)
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] Question related with URIConverters and URIHandler (again) [message #428118 is a reply to message #428103] |
Wed, 11 March 2009 11:49 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Ed,
thanks for your quick answer and excuses for my late one :P
comments below
>> may I ask you, is there a reason why there doesn't exist an extension
>> point for contributing new URIHandlers to ExtensibleURIConverterImpl?
> Yes, you may ask. :-P
>
> There is a danger in supporting such a thing because the handlers are
> consulted in sequence and the longer that sequence, the more the
> overhead. Suppose 100 components all decided their handler is really
> cool and should be available for everyone, well at least as far as their
> use of EMF is concerned.
I see your point. But why not using a mapping strategy like the one used
for Resource.Factory: mapping per URI scheme. I guess a URIHandler could
manage several URI schemes (as EFS does) ...
>> This resource could be a CDOResource. I believe the only way we can get
>> the correct behaviour of "exist()" is contributing a new URIHandler to
>> the URIConverter that understands CDO URIs. We could do that
>> programmatically adding such URIHandler, but we would like to avoid
>> dependencies in our code with CDO bundles.
> So you could define an extension point. :-P Don't your models already
> depend on CDOEObjectImpl?
Yeah, models indeed depend on org.eclipse.emf.cdo, but not code using
these models doesn't distinguish whether these models are persisted in
CDO or not.
Now that I think about it, maybe we could inject the CDO specific
URIHandler when Resource.Internal.basicSetResourceSet() is called on
CDOResource...
>>
>> Another solution would be creating our own URIConverter that extends
>> ExtensibleURIConverterImpl and allows contribution through extension
>> point.
>>
>> Yet another solution could be integrating CDO with EFS and using
>> EFSHandler...
> I was going to suggest that. That probably has some other significant
> benefits as well...
I believe such integration is on the way :) but don't know the status :(
|
|
|
| Re: [EMF] Question related with URIConverters and URIHandler (again) [message #428119 is a reply to message #428118] |
Wed, 11 March 2009 12:02 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Víctor,
Comments below.
Víctor Roldán Betancort wrote:
> Ed,
>
> thanks for your quick answer and excuses for my late one :P
>
> comments below
>
>>> may I ask you, is there a reason why there doesn't exist an extension
>>> point for contributing new URIHandlers to ExtensibleURIConverterImpl?
>> Yes, you may ask. :-P
>>
>> There is a danger in supporting such a thing because the handlers are
>> consulted in sequence and the longer that sequence, the more the
>> overhead. Suppose 100 components all decided their handler is really
>> cool and should be available for everyone, well at least as far as
>> their use of EMF is concerned.
>
> I see your point. But why not using a mapping strategy like the one
> used for Resource.Factory: mapping per URI scheme.
That's certainly possible, but not as flexible as the current approach
which allows anything to be selectively filtered and handled in a
special way. I.e., perhaps based on the authority or some other aspect
of the URI.
> I guess a URIHandler could manage several URI schemes (as EFS does) ...
>
>>> This resource could be a CDOResource. I believe the only way we can get
>>> the correct behaviour of "exist()" is contributing a new URIHandler to
>>> the URIConverter that understands CDO URIs. We could do that
>>> programmatically adding such URIHandler, but we would like to avoid
>>> dependencies in our code with CDO bundles.
>> So you could define an extension point. :-P Don't your models
>> already depend on CDOEObjectImpl?
>
> Yeah, models indeed depend on org.eclipse.emf.cdo, but not code using
> these models doesn't distinguish whether these models are persisted in
> CDO or not.
>
> Now that I think about it, maybe we could inject the CDO specific
> URIHandler when Resource.Internal.basicSetResourceSet() is called on
> CDOResource...
Where there's a will there's a way. I get the sense that CDO provides
quite a few options that clients are likely to want to tune whereas a
contribution would inject one choice for all clients...
>
>>>
>>> Another solution would be creating our own URIConverter that extends
>>> ExtensibleURIConverterImpl and allows contribution through extension
>>> point.
>>>
>>> Yet another solution could be integrating CDO with EFS and using
>>> EFSHandler...
>> I was going to suggest that. That probably has some other
>> significant benefits as well...
>
> I believe such integration is on the way :) but don't know the status :(
I'd heard it was quite cool and good. :-P
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [EMF] Question related with URIConverters and URIHandler (again) [message #428121 is a reply to message #428118] |
Wed, 11 March 2009 12:08 |
|
Vik,
Comments below...
Víctor Roldán Betancort schrieb:
> Ed,
>
> thanks for your quick answer and excuses for my late one :P
>
> comments below
>
>>> may I ask you, is there a reason why there doesn't exist an extension
>>> point for contributing new URIHandlers to ExtensibleURIConverterImpl?
>> Yes, you may ask. :-P
>>
>> There is a danger in supporting such a thing because the handlers are
>> consulted in sequence and the longer that sequence, the more the
>> overhead. Suppose 100 components all decided their handler is really
>> cool and should be available for everyone, well at least as far as
>> their use of EMF is concerned.
>
> I see your point. But why not using a mapping strategy like the one
> used for Resource.Factory: mapping per URI scheme. I guess a
> URIHandler could manage several URI schemes (as EFS does) ...
>
>>> This resource could be a CDOResource. I believe the only way we can get
>>> the correct behaviour of "exist()" is contributing a new URIHandler to
>>> the URIConverter that understands CDO URIs. We could do that
>>> programmatically adding such URIHandler, but we would like to avoid
>>> dependencies in our code with CDO bundles.
>> So you could define an extension point. :-P Don't your models
>> already depend on CDOEObjectImpl?
>
> Yeah, models indeed depend on org.eclipse.emf.cdo, but not code using
> these models doesn't distinguish whether these models are persisted in
> CDO or not.
>
> Now that I think about it, maybe we could inject the CDO specific
> URIHandler when Resource.Internal.basicSetResourceSet() is called on
> CDOResource...
Wouldn't that be part of the CDOViewSet initialization (which manages
the CDO aspects of a ResourceSet)?
>
>>>
>>> Another solution would be creating our own URIConverter that extends
>>> ExtensibleURIConverterImpl and allows contribution through extension
>>> point.
>>>
>>> Yet another solution could be integrating CDO with EFS and using
>>> EFSHandler...
>> I was going to suggest that. That probably has some other
>> significant benefits as well...
>
> I believe such integration is on the way :) but don't know the status :(
Bernd Kolb was working on it, but I did not hear about the status for
some while.
Cheers
/Eike
----
http://thegordian.blogspot.com
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [EMF] Question related with URIConverters and URIHandler (again) [message #428133 is a reply to message #428119] |
Wed, 11 March 2009 15:16 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Ed,
>> Now that I think about it, maybe we could inject the CDO specific
>> URIHandler when Resource.Internal.basicSetResourceSet() is called on
>> CDOResource...
> Where there's a will there's a way. I get the sense that CDO provides
> quite a few options that clients are likely to want to tune whereas a
> contribution would inject one choice for all clients...
Good point. From a pure EMF point of view, user don't know about lot of
the concepts that CDO providers, like sessions, views, transactions,
audits...
However, if for some reason they are using CDO URIs, I guess they
already know there are some requirements other than having your model
defined and the URI of your resource. For that, we've provided an
extension point to let them decide how to prepare the session and views
behind the scenes, so ResourceSet will know how to resolve CDO URIs
without additional information or prior preparation (i.e., adapters).
I guess URIConverter and URIHandler could benefit from it as well, but
there still some part of the contract that I'm not sure how to solve
(URIHandler.createInputStream() and URIHandler.createOutputStream()).
The point is trying to get as much EMF compliance as possible, and thats
one of our main goals. Sometimes that might imply having only "one way",
but hey, better one than none! :P
Cheers,
ViK.
|
|
|
| Re: [EMF] Question related with URIConverters and URIHandler (again) [message #428139 is a reply to message #428133] |
Wed, 11 March 2009 16:52 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Víctor,
I've talked to Eike about some of these improved integration points.
Given that CDO involves a live connection, it seems to me that something
like createInputStream ought to create the connection and could be
designed to return the connection information in the stream.
Similarly, the create output stream could kick off a commit... We could
have a conf call at some point to discuss this stuff...
Víctor Roldán Betancort wrote:
> Ed,
>
>>> Now that I think about it, maybe we could inject the CDO specific
>>> URIHandler when Resource.Internal.basicSetResourceSet() is called on
>>> CDOResource...
>> Where there's a will there's a way. I get the sense that CDO
>> provides quite a few options that clients are likely to want to tune
>> whereas a contribution would inject one choice for all clients...
>
> Good point. From a pure EMF point of view, user don't know about lot
> of the concepts that CDO providers, like sessions, views,
> transactions, audits...
>
> However, if for some reason they are using CDO URIs, I guess they
> already know there are some requirements other than having your model
> defined and the URI of your resource. For that, we've provided an
> extension point to let them decide how to prepare the session and
> views behind the scenes, so ResourceSet will know how to resolve CDO
> URIs without additional information or prior preparation (i.e.,
> adapters).
>
> I guess URIConverter and URIHandler could benefit from it as well, but
> there still some part of the contract that I'm not sure how to solve
> (URIHandler.createInputStream() and URIHandler.createOutputStream()).
>
> The point is trying to get as much EMF compliance as possible, and
> thats one of our main goals. Sometimes that might imply having only
> "one way", but hey, better one than none! :P
>
> Cheers,
> ViK.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 14:01:23 GMT 2024
Powered by FUDForum. Page generated in 0.04370 seconds |
] 
Search
Help
Register
Login
Home
