Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] XMI models referencing elements stored in CDO
[CDO] XMI models referencing elements stored in CDO [message #422860] Wed, 17 September 2008 15:14 Go to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Hi guys,

while working on GMF + CDO integration, I realized how the "Notation"
model does extend the Ecore. I had the hope to be able to store the
notation instance together with the business model instance in a CDO
repository, but extending the Ecore implies that (at least for now)
"Notation" model instances cannot be stored in CDO.

So the alternative is having instances of the notation model (persisted
as an XMI file) referencing elements stored in CDO. So my question here
is related with reference resolution. How does this mechanism work? I
believe URIConverter/URIHandler does this work, is this right?

For instance, could we have something like this:

<element xmi:type="MyElement"
href=" cdo://repositoryHost:2036/fooPath#1234?repositoryName=fooRep o"/>

where the reference is persisted as a CDO URI.

Could this be resolved by having a CDOURIHandler and a ResourceSet with
the right ResourceFactory (CDOResourceFactory)?

Thanks in advance!
Re: [CDO] XMI models referencing elements stored in CDO [message #422862 is a reply to message #422860] Wed, 17 September 2008 15:30 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30806
Registered: July 2009
Senior Member
Víctor,

Comments below.

Víctor Roldán Betancort wrote:
> Hi guys,
>
> while working on GMF + CDO integration, I realized how the "Notation"
> model does extend the Ecore.
It's so annoying. Just to inherit support for annotations which could
simply have been modeled in the Notation model itself.
> I had the hope to be able to store the notation instance together with
> the business model instance in a CDO repository, but extending the
> Ecore implies that (at least for now) "Notation" model instances
> cannot be stored in CDO.
Isn't the Notation model a problem regardless of it's extension of Ecore?
>
> So the alternative is having instances of the notation model
> (persisted as an XMI file) referencing elements stored in CDO. So my
> question here is related with reference resolution. How does this
> mechanism work? I believe URIConverter/URIHandler does this work, is
> this right?
>
> For instance, could we have something like this:
>
> <element xmi:type="MyElement"
> href=" cdo://repositoryHost:2036/fooPath#1234?repositoryName=fooRep o"/>
>
> where the reference is persisted as a CDO URI.
>
> Could this be resolved by having a CDOURIHandler and a ResourceSet
> with the right ResourceFactory (CDOResourceFactory)?
I hope so!
>
> Thanks in advance!
>
Re: [CDO] XMI models referencing elements stored in CDO [message #422863 is a reply to message #422862] Wed, 17 September 2008 15:41 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Ed,

>> I had the hope to be able to store the notation instance together with
>> the business model instance in a CDO repository, but extending the
>> Ecore implies that (at least for now) "Notation" model instances
>> cannot be stored in CDO.
> Isn't the Notation model a problem regardless of it's extension of Ecore?

I wish I didn't exist... but between annotating the business model and
having a decorator model, I prefer a decorator model...

>> Could this be resolved by having a CDOURIHandler and a ResourceSet
>> with the right ResourceFactory (CDOResourceFactory)?
> I hope so!

Thanks Ed! I'll play around with these a little bit!

>>
>> Thanks in advance!
>>
Re: [CDO] XMI models referencing elements stored in CDO [message #422864 is a reply to message #422862] Wed, 17 September 2008 15:52 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Ed,

I forgot something else. Would it be enough by just having the
ResourceFactory? Are the URIConverter/URIHandler indispensable for this
task? It seems to me these classes are kind of an (more convenient?)
alternative to the ResourceFactory for the URI resolution task.
Re: [CDO] XMI models referencing elements stored in CDO [message #422865 is a reply to message #422864] Wed, 17 September 2008 16:20 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30806
Registered: July 2009
Senior Member
Víctor,

The resource factory is responsible for creating a resource that knows
how to handle a specific type/form of content. The
URIConverter/URIHandler is responsible for the communication between the
resource and the backing store that supplies the bytes representing the
content. I know that CDO maintains a live connection. But I could
imagine URIConverter.createInputStream returning a small "dummy" stream
that yields the information about the established connection which is
then processed and used to prime the resource. Similarly the
createOutputStream could be used to kick of the commit process. (But
since I don't know the details, this is all very vague.)


Víctor Roldán Betancort wrote:
> Ed,
>
> I forgot something else. Would it be enough by just having the
> ResourceFactory? Are the URIConverter/URIHandler indispensable for
> this task? It seems to me these classes are kind of an (more
> convenient?) alternative to the ResourceFactory for the URI resolution
> task.
Re: [CDO] XMI models referencing elements stored in CDO [message #422867 is a reply to message #422865] Wed, 17 September 2008 17:47 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Ed,

> The resource factory is responsible for creating a resource that knows
> how to handle a specific type/form of content. The
> URIConverter/URIHandler is responsible for the communication between the
> resource and the backing store that supplies the bytes representing the
> content.

Thanks, good to know. I see it more clear now.

I'm not aware Eike nor Simon have created such thing as a CDOURIHandler,
so I suspect the CDOResource contains the logic to populate its content,
since it's already possible to get CDOResources from a ResourceSet. So
it probably bypasses the URIConverter/URIHandler part.

> I know that CDO maintains a live connection. But I could
> imagine URIConverter.createInputStream returning a small "dummy" stream
> that yields the information about the established connection which is
> then processed and used to prime the resource. Similarly the
> createOutputStream could be used to kick of the commit process. (But
> since I don't know the details, this is all very vague.)

I'm not sure if this would be possible. Eike told me several times CDO
is not very stream-friendly... There is a signaling infrastructure for
communication between client and repository... maybe it's possible to
get and wrap the streams coming from them?
Re: [CDO] XMI models referencing elements stored in CDO [message #422868 is a reply to message #422867] Wed, 17 September 2008 18:13 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30806
Registered: July 2009
Senior Member
Víctor,

I'm imagining they'd use the URI converter only to initiate a connection
using createInputStream, and initiate a commit using
createOutputStream. The streams would/could contain on the some data
about the operation/connection.



Víctor Roldán Betancort wrote:
> Ed,
>
>> The resource factory is responsible for creating a resource that
>> knows how to handle a specific type/form of content. The
>> URIConverter/URIHandler is responsible for the communication between
>> the resource and the backing store that supplies the bytes
>> representing the content.
>
> Thanks, good to know. I see it more clear now.
>
> I'm not aware Eike nor Simon have created such thing as a
> CDOURIHandler, so I suspect the CDOResource contains the logic to
> populate its content, since it's already possible to get CDOResources
> from a ResourceSet. So it probably bypasses the
> URIConverter/URIHandler part.
>
>> I know that CDO maintains a live connection. But I could imagine
>> URIConverter.createInputStream returning a small "dummy" stream that
>> yields the information about the established connection which is then
>> processed and used to prime the resource. Similarly the
>> createOutputStream could be used to kick of the commit process. (But
>> since I don't know the details, this is all very vague.)
>
> I'm not sure if this would be possible. Eike told me several times CDO
> is not very stream-friendly... There is a signaling infrastructure for
> communication between client and repository... maybe it's possible to
> get and wrap the streams coming from them?
Re: [CDO] XMI models referencing elements stored in CDO [message #422869 is a reply to message #422868] Wed, 17 September 2008 18:49 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Ed,

good news! I made it work to load a CDOResource referenced in a XMI
persisted model :D! Now I have to fix why the editor keeps loading the
resource ad infinitum :P

This way I won't need to implement CDOURIHandler (although several
different issues seems to need it...).

Ed Merks escribió:
> Víctor,
>
> I'm imagining they'd use the URI converter only to initiate a connection
> using createInputStream, and initiate a commit using
> createOutputStream. The streams would/could contain on the some data
> about the operation/connection.
>
>
>
> Víctor Roldán Betancort wrote:
>> Ed,
>>
>>> The resource factory is responsible for creating a resource that
>>> knows how to handle a specific type/form of content. The
>>> URIConverter/URIHandler is responsible for the communication between
>>> the resource and the backing store that supplies the bytes
>>> representing the content.
>>
>> Thanks, good to know. I see it more clear now.
>>
>> I'm not aware Eike nor Simon have created such thing as a
>> CDOURIHandler, so I suspect the CDOResource contains the logic to
>> populate its content, since it's already possible to get CDOResources
>> from a ResourceSet. So it probably bypasses the
>> URIConverter/URIHandler part.
>>
>>> I know that CDO maintains a live connection. But I could imagine
>>> URIConverter.createInputStream returning a small "dummy" stream that
>>> yields the information about the established connection which is then
>>> processed and used to prime the resource. Similarly the
>>> createOutputStream could be used to kick of the commit process. (But
>>> since I don't know the details, this is all very vague.)
>>
>> I'm not sure if this would be possible. Eike told me several times CDO
>> is not very stream-friendly... There is a signaling infrastructure for
>> communication between client and repository... maybe it's possible to
>> get and wrap the streams coming from them?
Re: [CDO] XMI models referencing elements stored in CDO [message #422870 is a reply to message #422869] Wed, 17 September 2008 18:53 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30806
Registered: July 2009
Senior Member
Víctor,

It's great to see all the collaborative effort around CDO taking place
so openly!


Víctor Roldán Betancort wrote:
> Ed,
>
> good news! I made it work to load a CDOResource referenced in a XMI
> persisted model :D! Now I have to fix why the editor keeps loading the
> resource ad infinitum :P
>
> This way I won't need to implement CDOURIHandler (although several
> different issues seems to need it...).
>
> Ed Merks escribió:
>> Víctor,
>>
>> I'm imagining they'd use the URI converter only to initiate a
>> connection using createInputStream, and initiate a commit using
>> createOutputStream. The streams would/could contain on the some data
>> about the operation/connection.
>>
>>
>>
>> Víctor Roldán Betancort wrote:
>>> Ed,
>>>
>>>> The resource factory is responsible for creating a resource that
>>>> knows how to handle a specific type/form of content. The
>>>> URIConverter/URIHandler is responsible for the communication
>>>> between the resource and the backing store that supplies the bytes
>>>> representing the content.
>>>
>>> Thanks, good to know. I see it more clear now.
>>>
>>> I'm not aware Eike nor Simon have created such thing as a
>>> CDOURIHandler, so I suspect the CDOResource contains the logic to
>>> populate its content, since it's already possible to get
>>> CDOResources from a ResourceSet. So it probably bypasses the
>>> URIConverter/URIHandler part.
>>>
>>>> I know that CDO maintains a live connection. But I could imagine
>>>> URIConverter.createInputStream returning a small "dummy" stream
>>>> that yields the information about the established connection which
>>>> is then processed and used to prime the resource. Similarly the
>>>> createOutputStream could be used to kick of the commit process.
>>>> (But since I don't know the details, this is all very vague.)
>>>
>>> I'm not sure if this would be possible. Eike told me several times
>>> CDO is not very stream-friendly... There is a signaling
>>> infrastructure for communication between client and repository...
>>> maybe it's possible to get and wrap the streams coming from them?
Re: [CDO] XMI models referencing elements stored in CDO [message #422875 is a reply to message #422865] Wed, 17 September 2008 19:52 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
Guys,

I'm seeing that InputStream/OutputStream are very basic concpets
(unfortunately without proper interfaces) and complyance to them would
open a whole bunch of new possibilities to integrate with other
technologies (like EFS). The point is that I just don't see *how* to
make this work. The natures of a stream and a stateful remote connection
are so different. Could you imagine to use the document-oriented
paradigm of a word processor in the same way as you work with fine
grained objects in a repository/database through a live connection?

I ask myself what the client of a stream might expect from using it.
Most probably it will read from it until end of stream is reached and do
all its work while pulling form the stream or shortly after finishing
that. Then it usually closes the stream and throws it away!

Hit me but I don't see a way to remember the connection data in the
stream and make it avaliable to a stream based client after that point
in time. The only real alternative would be to do everything so that the
client will not have to need the conncetion info later. For CDO that
would mean i.e. pre-loading the whole containment structure of a
resource and disable the remote updates that enable the distributed
shared model features of CDO. Maybe the latter problem could be
addressed to some degree for clients that have a little more knowledge
about data source than just "InputStream" (e.g. IFile with change
notification stuff).

The OutputStream/commit analogy seems to be a bit less unfortunate
because currently CDO only offers an optimistic locking strategy over
the network. I wonder what the impact of Bugzilla 247427 might be...

247427: Explicit locking
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247427

Cheers
/Eike


Ed Merks schrieb:
> Víctor,
>
> The resource factory is responsible for creating a resource that knows
> how to handle a specific type/form of content. The
> URIConverter/URIHandler is responsible for the communication between
> the resource and the backing store that supplies the bytes
> representing the content. I know that CDO maintains a live
> connection. But I could imagine URIConverter.createInputStream
> returning a small "dummy" stream that yields the information about the
> established connection which is then processed and used to prime the
> resource. Similarly the createOutputStream could be used to kick of
> the commit process. (But since I don't know the details, this is all
> very vague.)
>
>
> Víctor Roldán Betancort wrote:
>> Ed,
>>
>> I forgot something else. Would it be enough by just having the
>> ResourceFactory? Are the URIConverter/URIHandler indispensable for
>> this task? It seems to me these classes are kind of an (more
>> convenient?) alternative to the ResourceFactory for the URI
>> resolution task.


Re: [CDO] XMI models referencing elements stored in CDO [message #422877 is a reply to message #422875] Wed, 17 September 2008 20:29 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30806
Registered: July 2009
Senior Member
Eike,

I keep imagining the creation of the input stream would establish the
connection and would return in the stream itself, the information the
resource would need to communicate directly with the server. No actual
instance data would be transmitted through the stream, just " metadata"
about the connection itself. Probably we should talk on skype when next
I get a chance... Maybe on Friday...


Eike Stepper wrote:
> Guys,
>
> I'm seeing that InputStream/OutputStream are very basic concpets
> (unfortunately without proper interfaces) and complyance to them would
> open a whole bunch of new possibilities to integrate with other
> technologies (like EFS). The point is that I just don't see *how* to
> make this work. The natures of a stream and a stateful remote
> connection are so different. Could you imagine to use the
> document-oriented paradigm of a word processor in the same way as you
> work with fine grained objects in a repository/database through a live
> connection?
>
> I ask myself what the client of a stream might expect from using it.
> Most probably it will read from it until end of stream is reached and
> do all its work while pulling form the stream or shortly after
> finishing that. Then it usually closes the stream and throws it away!
>
> Hit me but I don't see a way to remember the connection data in the
> stream and make it avaliable to a stream based client after that point
> in time. The only real alternative would be to do everything so that
> the client will not have to need the conncetion info later. For CDO
> that would mean i.e. pre-loading the whole containment structure of a
> resource and disable the remote updates that enable the distributed
> shared model features of CDO. Maybe the latter problem could be
> addressed to some degree for clients that have a little more knowledge
> about data source than just "InputStream" (e.g. IFile with change
> notification stuff).
>
> The OutputStream/commit analogy seems to be a bit less unfortunate
> because currently CDO only offers an optimistic locking strategy over
> the network. I wonder what the impact of Bugzilla 247427 might be...
>
> 247427: Explicit locking
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247427
>
> Cheers
> /Eike
>
>
> Ed Merks schrieb:
>> Víctor,
>>
>> The resource factory is responsible for creating a resource that
>> knows how to handle a specific type/form of content. The
>> URIConverter/URIHandler is responsible for the communication between
>> the resource and the backing store that supplies the bytes
>> representing the content. I know that CDO maintains a live
>> connection. But I could imagine URIConverter.createInputStream
>> returning a small "dummy" stream that yields the information about
>> the established connection which is then processed and used to prime
>> the resource. Similarly the createOutputStream could be used to kick
>> of the commit process. (But since I don't know the details, this is
>> all very vague.)
>>
>>
>> Víctor Roldán Betancort wrote:
>>> Ed,
>>>
>>> I forgot something else. Would it be enough by just having the
>>> ResourceFactory? Are the URIConverter/URIHandler indispensable for
>>> this task? It seems to me these classes are kind of an (more
>>> convenient?) alternative to the ResourceFactory for the URI
>>> resolution task.
Re: [CDO] XMI models referencing elements stored in CDO [message #422880 is a reply to message #422877] Wed, 17 September 2008 21:06 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
Ed Merks schrieb:
> Eike,
>
> I keep imagining the creation of the input stream would establish the
> connection and would return in the stream itself, the information the
> resource would need to communicate directly with the server. No
> actual instance data would be transmitted through the stream, just "
> metadata" about the connection itself. Probably we should talk on
> skype when next I get a chance... Maybe on Friday...
Yes, as long as the stream-wrapping approach is only used to integrate
one framework with the other (as opposed to an existing application) I
think it's worth discussing it. I'm always here. And have a whole bunch
of other things to discuss as well :P

Cheers
/Eike

>
>
> Eike Stepper wrote:
>> Guys,
>>
>> I'm seeing that InputStream/OutputStream are very basic concpets
>> (unfortunately without proper interfaces) and complyance to them
>> would open a whole bunch of new possibilities to integrate with other
>> technologies (like EFS). The point is that I just don't see *how* to
>> make this work. The natures of a stream and a stateful remote
>> connection are so different. Could you imagine to use the
>> document-oriented paradigm of a word processor in the same way as you
>> work with fine grained objects in a repository/database through a
>> live connection?
>>
>> I ask myself what the client of a stream might expect from using it.
>> Most probably it will read from it until end of stream is reached and
>> do all its work while pulling form the stream or shortly after
>> finishing that. Then it usually closes the stream and throws it away!
>>
>> Hit me but I don't see a way to remember the connection data in the
>> stream and make it avaliable to a stream based client after that
>> point in time. The only real alternative would be to do everything so
>> that the client will not have to need the conncetion info later. For
>> CDO that would mean i.e. pre-loading the whole containment structure
>> of a resource and disable the remote updates that enable the
>> distributed shared model features of CDO. Maybe the latter problem
>> could be addressed to some degree for clients that have a little more
>> knowledge about data source than just "InputStream" (e.g. IFile with
>> change notification stuff).
>>
>> The OutputStream/commit analogy seems to be a bit less unfortunate
>> because currently CDO only offers an optimistic locking strategy over
>> the network. I wonder what the impact of Bugzilla 247427 might be...
>>
>> 247427: Explicit locking
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247427
>>
>> Cheers
>> /Eike
>>
>>
>> Ed Merks schrieb:
>>> Víctor,
>>>
>>> The resource factory is responsible for creating a resource that
>>> knows how to handle a specific type/form of content. The
>>> URIConverter/URIHandler is responsible for the communication between
>>> the resource and the backing store that supplies the bytes
>>> representing the content. I know that CDO maintains a live
>>> connection. But I could imagine URIConverter.createInputStream
>>> returning a small "dummy" stream that yields the information about
>>> the established connection which is then processed and used to prime
>>> the resource. Similarly the createOutputStream could be used to
>>> kick of the commit process. (But since I don't know the details,
>>> this is all very vague.)
>>>
>>>
>>> Víctor Roldán Betancort wrote:
>>>> Ed,
>>>>
>>>> I forgot something else. Would it be enough by just having the
>>>> ResourceFactory? Are the URIConverter/URIHandler indispensable for
>>>> this task? It seems to me these classes are kind of an (more
>>>> convenient?) alternative to the ResourceFactory for the URI
>>>> resolution task.


Re: [CDO] XMI models referencing elements stored in CDO [message #422883 is a reply to message #422880] Wed, 17 September 2008 21:14 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
Eike Stepper schrieb:
> Ed Merks schrieb:
>> Eike,
>>
>> I keep imagining the creation of the input stream would establish the
>> connection and would return in the stream itself, the information the
>> resource would need to communicate directly with the server. No
>> actual instance data would be transmitted through the stream, just "
>> metadata" about the connection itself. Probably we should talk on
>> skype when next I get a chance... Maybe on Friday...
> Yes, as long as the stream-wrapping approach is only used to integrate
> one framework with the other (as opposed to an existing application)
The difference is that the first only uses ("abuses") the stream as
suitable carrier for stream-unrelated data while the latter would
require the read() method to return something meaningful to an application.


> I think it's worth discussing it. I'm always here. And have a whole
> bunch of other things to discuss as well :P
>
> Cheers
> /Eike
>
>>
>>
>> Eike Stepper wrote:
>>> Guys,
>>>
>>> I'm seeing that InputStream/OutputStream are very basic concpets
>>> (unfortunately without proper interfaces) and complyance to them
>>> would open a whole bunch of new possibilities to integrate with
>>> other technologies (like EFS). The point is that I just don't see
>>> *how* to make this work. The natures of a stream and a stateful
>>> remote connection are so different. Could you imagine to use the
>>> document-oriented paradigm of a word processor in the same way as
>>> you work with fine grained objects in a repository/database through
>>> a live connection?
>>>
>>> I ask myself what the client of a stream might expect from using it.
>>> Most probably it will read from it until end of stream is reached
>>> and do all its work while pulling form the stream or shortly after
>>> finishing that. Then it usually closes the stream and throws it away!
>>>
>>> Hit me but I don't see a way to remember the connection data in the
>>> stream and make it avaliable to a stream based client after that
>>> point in time. The only real alternative would be to do everything
>>> so that the client will not have to need the conncetion info later.
>>> For CDO that would mean i.e. pre-loading the whole containment
>>> structure of a resource and disable the remote updates that enable
>>> the distributed shared model features of CDO. Maybe the latter
>>> problem could be addressed to some degree for clients that have a
>>> little more knowledge about data source than just "InputStream"
>>> (e.g. IFile with change notification stuff).
>>>
>>> The OutputStream/commit analogy seems to be a bit less unfortunate
>>> because currently CDO only offers an optimistic locking strategy
>>> over the network. I wonder what the impact of Bugzilla 247427 might
>>> be...
>>>
>>> 247427: Explicit locking
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247427
>>>
>>> Cheers
>>> /Eike
>>>
>>>
>>> Ed Merks schrieb:
>>>> Víctor,
>>>>
>>>> The resource factory is responsible for creating a resource that
>>>> knows how to handle a specific type/form of content. The
>>>> URIConverter/URIHandler is responsible for the communication
>>>> between the resource and the backing store that supplies the bytes
>>>> representing the content. I know that CDO maintains a live
>>>> connection. But I could imagine URIConverter.createInputStream
>>>> returning a small "dummy" stream that yields the information about
>>>> the established connection which is then processed and used to
>>>> prime the resource. Similarly the createOutputStream could be used
>>>> to kick of the commit process. (But since I don't know the
>>>> details, this is all very vague.)
>>>>
>>>>
>>>> Víctor Roldán Betancort wrote:
>>>>> Ed,
>>>>>
>>>>> I forgot something else. Would it be enough by just having the
>>>>> ResourceFactory? Are the URIConverter/URIHandler indispensable for
>>>>> this task? It seems to me these classes are kind of an (more
>>>>> convenient?) alternative to the ResourceFactory for the URI
>>>>> resolution task.


Re: [CDO] XMI models referencing elements stored in CDO [message #422884 is a reply to message #422883] Wed, 17 September 2008 21:17 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30806
Registered: July 2009
Senior Member
Eike,

I don't see it as an abuse, because you can imagine, exists, delete, and
even getAttributes/setAttributes being useful in the overall resource
life cycle. But yes, we can talk when I have some time. :-)


Eike Stepper wrote:
>
>
> Eike Stepper schrieb:
>> Ed Merks schrieb:
>>> Eike,
>>>
>>> I keep imagining the creation of the input stream would establish
>>> the connection and would return in the stream itself, the
>>> information the resource would need to communicate directly with the
>>> server. No actual instance data would be transmitted through the
>>> stream, just " metadata" about the connection itself. Probably we
>>> should talk on skype when next I get a chance... Maybe on Friday...
>> Yes, as long as the stream-wrapping approach is only used to
>> integrate one framework with the other (as opposed to an existing
>> application)
> The difference is that the first only uses ("abuses") the stream as
> suitable carrier for stream-unrelated data while the latter would
> require the read() method to return something meaningful to an
> application.
>
>
>> I think it's worth discussing it. I'm always here. And have a whole
>> bunch of other things to discuss as well :P
>>
>> Cheers
>> /Eike
>>
>>>
>>>
>>> Eike Stepper wrote:
>>>> Guys,
>>>>
>>>> I'm seeing that InputStream/OutputStream are very basic concpets
>>>> (unfortunately without proper interfaces) and complyance to them
>>>> would open a whole bunch of new possibilities to integrate with
>>>> other technologies (like EFS). The point is that I just don't see
>>>> *how* to make this work. The natures of a stream and a stateful
>>>> remote connection are so different. Could you imagine to use the
>>>> document-oriented paradigm of a word processor in the same way as
>>>> you work with fine grained objects in a repository/database through
>>>> a live connection?
>>>>
>>>> I ask myself what the client of a stream might expect from using
>>>> it. Most probably it will read from it until end of stream is
>>>> reached and do all its work while pulling form the stream or
>>>> shortly after finishing that. Then it usually closes the stream and
>>>> throws it away!
>>>>
>>>> Hit me but I don't see a way to remember the connection data in the
>>>> stream and make it avaliable to a stream based client after that
>>>> point in time. The only real alternative would be to do everything
>>>> so that the client will not have to need the conncetion info later.
>>>> For CDO that would mean i.e. pre-loading the whole containment
>>>> structure of a resource and disable the remote updates that enable
>>>> the distributed shared model features of CDO. Maybe the latter
>>>> problem could be addressed to some degree for clients that have a
>>>> little more knowledge about data source than just "InputStream"
>>>> (e.g. IFile with change notification stuff).
>>>>
>>>> The OutputStream/commit analogy seems to be a bit less unfortunate
>>>> because currently CDO only offers an optimistic locking strategy
>>>> over the network. I wonder what the impact of Bugzilla 247427 might
>>>> be...
>>>>
>>>> 247427: Explicit locking
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247427
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>
>>>> Ed Merks schrieb:
>>>>> Víctor,
>>>>>
>>>>> The resource factory is responsible for creating a resource that
>>>>> knows how to handle a specific type/form of content. The
>>>>> URIConverter/URIHandler is responsible for the communication
>>>>> between the resource and the backing store that supplies the bytes
>>>>> representing the content. I know that CDO maintains a live
>>>>> connection. But I could imagine URIConverter.createInputStream
>>>>> returning a small "dummy" stream that yields the information about
>>>>> the established connection which is then processed and used to
>>>>> prime the resource. Similarly the createOutputStream could be
>>>>> used to kick of the commit process. (But since I don't know the
>>>>> details, this is all very vague.)
>>>>>
>>>>>
>>>>> Víctor Roldán Betancort wrote:
>>>>>> Ed,
>>>>>>
>>>>>> I forgot something else. Would it be enough by just having the
>>>>>> ResourceFactory? Are the URIConverter/URIHandler indispensable
>>>>>> for this task? It seems to me these classes are kind of an (more
>>>>>> convenient?) alternative to the ResourceFactory for the URI
>>>>>> resolution task.
Re: [CDO] XMI models referencing elements stored in CDO [message #422886 is a reply to message #422884] Wed, 17 September 2008 21:21 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
Ed Merks schrieb:
> Eike,
>
> I don't see it as an abuse, because you can imagine, exists, delete,
> and even getAttributes/setAttributes being useful in the overall
> resource life cycle.
I didn't mean "abuse" WRT the URIConverter/Handler but only WRT the
stream usage ;-)
I'm sure the URIConverter has some methods that we should support no
matter how we proceed with the stream issue.

> But yes, we can talk when I have some time. :-)
>
>
> Eike Stepper wrote:
>>
>>
>> Eike Stepper schrieb:
>>> Ed Merks schrieb:
>>>> Eike,
>>>>
>>>> I keep imagining the creation of the input stream would establish
>>>> the connection and would return in the stream itself, the
>>>> information the resource would need to communicate directly with
>>>> the server. No actual instance data would be transmitted through
>>>> the stream, just " metadata" about the connection itself. Probably
>>>> we should talk on skype when next I get a chance... Maybe on
>>>> Friday...
>>> Yes, as long as the stream-wrapping approach is only used to
>>> integrate one framework with the other (as opposed to an existing
>>> application)
>> The difference is that the first only uses ("abuses") the stream as
>> suitable carrier for stream-unrelated data while the latter would
>> require the read() method to return something meaningful to an
>> application.
>>
>>
>>> I think it's worth discussing it. I'm always here. And have a whole
>>> bunch of other things to discuss as well :P
>>>
>>> Cheers
>>> /Eike
>>>
>>>>
>>>>
>>>> Eike Stepper wrote:
>>>>> Guys,
>>>>>
>>>>> I'm seeing that InputStream/OutputStream are very basic concpets
>>>>> (unfortunately without proper interfaces) and complyance to them
>>>>> would open a whole bunch of new possibilities to integrate with
>>>>> other technologies (like EFS). The point is that I just don't see
>>>>> *how* to make this work. The natures of a stream and a stateful
>>>>> remote connection are so different. Could you imagine to use the
>>>>> document-oriented paradigm of a word processor in the same way as
>>>>> you work with fine grained objects in a repository/database
>>>>> through a live connection?
>>>>>
>>>>> I ask myself what the client of a stream might expect from using
>>>>> it. Most probably it will read from it until end of stream is
>>>>> reached and do all its work while pulling form the stream or
>>>>> shortly after finishing that. Then it usually closes the stream
>>>>> and throws it away!
>>>>>
>>>>> Hit me but I don't see a way to remember the connection data in
>>>>> the stream and make it avaliable to a stream based client after
>>>>> that point in time. The only real alternative would be to do
>>>>> everything so that the client will not have to need the conncetion
>>>>> info later. For CDO that would mean i.e. pre-loading the whole
>>>>> containment structure of a resource and disable the remote updates
>>>>> that enable the distributed shared model features of CDO. Maybe
>>>>> the latter problem could be addressed to some degree for clients
>>>>> that have a little more knowledge about data source than just
>>>>> "InputStream" (e.g. IFile with change notification stuff).
>>>>>
>>>>> The OutputStream/commit analogy seems to be a bit less unfortunate
>>>>> because currently CDO only offers an optimistic locking strategy
>>>>> over the network. I wonder what the impact of Bugzilla 247427
>>>>> might be...
>>>>>
>>>>> 247427: Explicit locking
>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247427
>>>>>
>>>>> Cheers
>>>>> /Eike
>>>>>
>>>>>
>>>>> Ed Merks schrieb:
>>>>>> Víctor,
>>>>>>
>>>>>> The resource factory is responsible for creating a resource that
>>>>>> knows how to handle a specific type/form of content. The
>>>>>> URIConverter/URIHandler is responsible for the communication
>>>>>> between the resource and the backing store that supplies the
>>>>>> bytes representing the content. I know that CDO maintains a live
>>>>>> connection. But I could imagine URIConverter.createInputStream
>>>>>> returning a small "dummy" stream that yields the information
>>>>>> about the established connection which is then processed and used
>>>>>> to prime the resource. Similarly the createOutputStream could be
>>>>>> used to kick of the commit process. (But since I don't know the
>>>>>> details, this is all very vague.)
>>>>>>
>>>>>>
>>>>>> Víctor Roldán Betancort wrote:
>>>>>>> Ed,
>>>>>>>
>>>>>>> I forgot something else. Would it be enough by just having the
>>>>>>> ResourceFactory? Are the URIConverter/URIHandler indispensable
>>>>>>> for this task? It seems to me these classes are kind of an (more
>>>>>>> convenient?) alternative to the ResourceFactory for the URI
>>>>>>> resolution task.


Re: [CDO] XMI models referencing elements stored in CDO [message #422902 is a reply to message #422886] Thu, 18 September 2008 12:36 Go to previous messageGo to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo HerreraFriend
Messages: 260
Registered: July 2009
Senior Member
Hi guys,

> I didn't mean "abuse" WRT the URIConverter/Handler but only WRT the
> stream usage ;-)
> I'm sure the URIConverter has some methods that we should support no
> matter how we proceed with the stream issue.

I agree, actually, I'm exploiting time stamp attribute to synchronize
on-memory resources in an easy way with Resource.getTimeStamp and
URIConverter.getAttributes, and CDO doesn't probably need to deal with
streams to do that (BTW, CDOResource is not managing time stamps, is it?).

However, AFAIK, CDO doesn't have
CDOResourceSet/CDOUriConverter/CDOUriHandler (which deals with streams)
to change in some point the way of doing such a thing (getting
attributes for a resource persisted in a data base,).

I think that everything that works fine for a XMI-persisted Resource, it
would be *very* nice if it worked for a DB-persisted CDOResource.

Besides, for EFS, it seems that CDO can't escape from dealing with
streams, at least if we want to have a robust integration (I hate having
unsopportedOperationExceptions ;P) with EFS.

As you said, Eike, I think that CDO could do a great step if we get a
nice solution to make CDO compatible with streams usage. I hope to
better study the situation soon, to be able to give a point of view of a
possible solution (if any ;P).

Cheers,
Adolfo.

>
>> But yes, we can talk when I have some time. :-)
>>
>>
>> Eike Stepper wrote:
>>>
>>>
>>> Eike Stepper schrieb:
>>>> Ed Merks schrieb:
>>>>> Eike,
>>>>>
>>>>> I keep imagining the creation of the input stream would establish
>>>>> the connection and would return in the stream itself, the
>>>>> information the resource would need to communicate directly with
>>>>> the server. No actual instance data would be transmitted through
>>>>> the stream, just " metadata" about the connection itself. Probably
>>>>> we should talk on skype when next I get a chance... Maybe on
>>>>> Friday...
>>>> Yes, as long as the stream-wrapping approach is only used to
>>>> integrate one framework with the other (as opposed to an existing
>>>> application)
>>> The difference is that the first only uses ("abuses") the stream as
>>> suitable carrier for stream-unrelated data while the latter would
>>> require the read() method to return something meaningful to an
>>> application.
>>>
>>>
>>>> I think it's worth discussing it. I'm always here. And have a whole
>>>> bunch of other things to discuss as well :P
>>>>
>>>> Cheers
>>>> /Eike
>>>>
>>>>>
>>>>>
>>>>> Eike Stepper wrote:
>>>>>> Guys,
>>>>>>
>>>>>> I'm seeing that InputStream/OutputStream are very basic concpets
>>>>>> (unfortunately without proper interfaces) and complyance to them
>>>>>> would open a whole bunch of new possibilities to integrate with
>>>>>> other technologies (like EFS). The point is that I just don't see
>>>>>> *how* to make this work. The natures of a stream and a stateful
>>>>>> remote connection are so different. Could you imagine to use the
>>>>>> document-oriented paradigm of a word processor in the same way as
>>>>>> you work with fine grained objects in a repository/database
>>>>>> through a live connection?
>>>>>>
>>>>>> I ask myself what the client of a stream might expect from using
>>>>>> it. Most probably it will read from it until end of stream is
>>>>>> reached and do all its work while pulling form the stream or
>>>>>> shortly after finishing that. Then it usually closes the stream
>>>>>> and throws it away!
>>>>>>
>>>>>> Hit me but I don't see a way to remember the connection data in
>>>>>> the stream and make it avaliable to a stream based client after
>>>>>> that point in time. The only real alternative would be to do
>>>>>> everything so that the client will not have to need the conncetion
>>>>>> info later. For CDO that would mean i.e. pre-loading the whole
>>>>>> containment structure of a resource and disable the remote updates
>>>>>> that enable the distributed shared model features of CDO. Maybe
>>>>>> the latter problem could be addressed to some degree for clients
>>>>>> that have a little more knowledge about data source than just
>>>>>> "InputStream" (e.g. IFile with change notification stuff).
>>>>>>
>>>>>> The OutputStream/commit analogy seems to be a bit less unfortunate
>>>>>> because currently CDO only offers an optimistic locking strategy
>>>>>> over the network. I wonder what the impact of Bugzilla 247427
>>>>>> might be...
>>>>>>
>>>>>> 247427: Explicit locking
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247427
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>>
>>>>>> Ed Merks schrieb:
>>>>>>> Víctor,
>>>>>>>
>>>>>>> The resource factory is responsible for creating a resource that
>>>>>>> knows how to handle a specific type/form of content. The
>>>>>>> URIConverter/URIHandler is responsible for the communication
>>>>>>> between the resource and the backing store that supplies the
>>>>>>> bytes representing the content. I know that CDO maintains a live
>>>>>>> connection. But I could imagine URIConverter.createInputStream
>>>>>>> returning a small "dummy" stream that yields the information
>>>>>>> about the established connection which is then processed and used
>>>>>>> to prime the resource. Similarly the createOutputStream could be
>>>>>>> used to kick of the commit process. (But since I don't know the
>>>>>>> details, this is all very vague.)
>>>>>>>
>>>>>>>
>>>>>>> Víctor Roldán Betancort wrote:
>>>>>>>> Ed,
>>>>>>>>
>>>>>>>> I forgot something else. Would it be enough by just having the
>>>>>>>> ResourceFactory? Are the URIConverter/URIHandler indispensable
>>>>>>>> for this task? It seems to me these classes are kind of an (more
>>>>>>>> convenient?) alternative to the ResourceFactory for the URI
>>>>>>>> resolution task.
Re: [CDO] XMI models referencing elements stored in CDO [message #422903 is a reply to message #422870] Thu, 18 September 2008 12:38 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Ed,

I've have another issues I would like to share here, regarding the URI
handling topic.

As I said, I created my own CDOResourceFactory. The different with the
default CDOResourceFactory is that mine is capable of create all the
necessary context to gather a resource from a CDO repository. CDO's
default one needs this context to be previously registered as an Adapter.

So my factory creates correctly the CDOResource. Remember that I told
that the resource is loaded in the editor in an infinite loop? This is
because the ResourceSet of the editor is never capable to determine that
the resource has been already created and loaded. The
URIConverter.normalize() method does this(so at the end, I still need
the CDOURIConverter :P)

What happens here? The "internal" URI of a CDOResource is quite
different from the external representation i'm using. So I need a
mechanism to map from an external CDO URI to an internal CDO URI.

Creating my own CDOURIConverter is not feasible right now, since implies
modifying the editor (right?). As far as I know, there is no such thing
as a URIConverterFactory extension point that puts the implementation in
a global URIConverter registry (which would be great for me right now
:P). The URI map extension point isn't feasible either, since I can only
know the mapping between URIs on runtime. So my last desperate solution
was to modify the global URI map, which you totally discourage.

Do I have any other alternatives?
Re: [CDO] XMI models referencing elements stored in CDO [message #422908 is a reply to message #422903] Thu, 18 September 2008 14:20 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
Víctor Roldán Betancort schrieb:
> Ed,
>
> I've have another issues I would like to share here, regarding the URI
> handling topic.
>
> As I said, I created my own CDOResourceFactory. The different with the
> default CDOResourceFactory is that mine is capable of create all the
> necessary context to gather a resource from a CDO repository. CDO's
> default one needs this context to be previously registered as an Adapter.
>
> So my factory creates correctly the CDOResource. Remember that I told
> that the resource is loaded in the editor in an infinite loop? This is
> because the ResourceSet of the editor is never capable to determine
> that the resource has been already created and loaded. The
> URIConverter.normalize() method does this(so at the end, I still need
> the CDOURIConverter :P)
>
> What happens here? The "internal" URI of a CDOResource is quite
> different from the external representation i'm using. So I need a
> mechanism to map from an external CDO URI to an internal CDO URI.
>
> Creating my own CDOURIConverter is not feasible right now, since
> implies modifying the editor (right?).
I guess only the ResourceSet. But if you have no other place to access
it rather than from the editor...

> As far as I know, there is no such thing as a URIConverterFactory
> extension point that puts the implementation in a global URIConverter
> registry (which would be great for me right now :P). The URI map
> extension point isn't feasible either, since I can only know the
> mapping between URIs on runtime.
I belive that you don't need to declare a URI mapping with a "full"
source URI but rather only a prefix. Would that help?

Cheers
/Eike


Re: [CDO] XMI models referencing elements stored in CDO [message #422910 is a reply to message #422908] Thu, 18 September 2008 14:37 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Eike,

> I belive that you don't need to declare a URI mapping with a "full"
> source URI but rather only a prefix. Would that help?

It wouldn't either, I need to obtain the repository UUID on runtime ...

>
> Cheers
> /Eike
Re: [CDO] XMI models referencing elements stored in CDO [message #422911 is a reply to message #422902] Thu, 18 September 2008 14:46 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------060300090806080605010903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Adolfo S


Re: [CDO] XMI models referencing elements stored in CDO [message #422912 is a reply to message #422910] Thu, 18 September 2008 14:48 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
Víctor Roldán Betancort schrieb:
> Eike,
>
>> I belive that you don't need to declare a URI mapping with a "full"
>> source URI but rather only a prefix. Would that help?
>
> It wouldn't either, I need to obtain the repository UUID on runtime ...
Why not use a new URI scheme and "URIhandle" this completely?

>
>>
>> Cheers
>> /Eike


Re: [CDO] XMI models referencing elements stored in CDO [message #422916 is a reply to message #422912] Thu, 18 September 2008 15:24 Go to previous messageGo to next message
Victor Roldan Betancort is currently offline Victor Roldan BetancortFriend
Messages: 524
Registered: July 2009
Senior Member
Eike,

> Why not use a new URI scheme and "URIhandle" this completely?

I believe I'll be in the same situation as with URIConverter. There is
no extension point for URIHandlers. To add this a new URIHandler to the
URIConverter, I'll be forced to modify somehow the code of the editor.
(URIHandler -> URIConverter -> ResourceSet -> TransactionalEditingDomain
-> Editor). Furthermore, I'm not sure if that's responsibility of the
URIHandler.

The editor will have to be modified anyway, so... I don't discard those
options.

>
>>
>>>
>>> Cheers
>>> /Eike
Re: [CDO] XMI models referencing elements stored in CDO [message #422917 is a reply to message #422911] Thu, 18 September 2008 15:39 Go to previous messageGo to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo HerreraFriend
Messages: 260
Registered: July 2009
Senior Member
Hi Eike,

Sorry for my bad "English", it's not the good it should be.

Some comments:


> No, because in CDO the granularity of commit/save is not the Resource
> but rather EObject. Each CDOTransaction can modify aribrary objects
> across all resource boundaries. All other CDOSessions in the wohle
> network (including additional local ones) are notified for each
> committed transaction. You can listen to their CDOSessionInvalidationEvents:
>
> | CDOSession session = ...;
> session.addListener(*new *IListener()
> {
> *public **void *notifyEvent(IEvent event)
> {
> *if *(event *instanceof *CDOSessionInvalidationEvent)
> {
> CDOSessionInvalidationEvent e = (CDOSessionInvalidationEvent)event;
> Set<CDOIDAndVersion> dirtyOIDs = e.getDirtyOIDs();
> *long *timeStamp = e.getTimeStamp();
> ...
> }
> }
> });|
>
>
> Notice how you can access the time stamp of the server transaction and
> the set of modified objects (through their IDs + versions). Perhaps this
> can be handy when computing the set of affected resources...
>
>

I should probably have said "CDOResource's time stamp is not being
managed". In EMF the own resource updates it when is loaded or saved.
CDO implementation should do it when a transaction commits or something
similar (Sorry again for not knowing CDO as well as I must know :( )

>>
>> However, AFAIK, CDO doesn't have
>> CDOResourceSet/CDOUriConverter/CDOUriHandler (which deals with
>> streams) to change in some point the way of doing such a thing
>> (getting attributes for a resource persisted in a data base,).
> I tend to believe that subtyping ResourceSet is a tabou (see earlier
> discussion here inthe newsgroup). I didn't understand the rest of your
> comment ;-(

What I meant, is that we can't get info about attributes of a
BD-persisted resource, if there is no specialization of one of those
classes (CDOUriHandler would probably be more convenient, exception that
it has the stream usage :( ).

>>
>> I think that everything that works fine for a XMI-persisted Resource,
>> it would be *very* nice if it worked for a DB-persisted CDOResource.
> In general I'd agree that everything that works fine for an EObject
> should work in the same way for a CDOObject. I hesitate a bit to
> generalize this statement to include the persistence mechanism as well.
> Would you suggest that we handle things like
> XMLResource.OPTION_PARSER_FEATURES as well? I mean, where do the
> similarities stop and where do the differences start?
> That said, we can certainly look at particular Resource features and
> revisit our decisions ;-)

That option doesn't seem to be candidate to support in CDO :D,
especially when we are talking about a XMLResource -.-. Maybe we should
focus on URIConverter/URIHandler API methods and Options. It seems that
asking if a Resource URI exists, if it is read only Resource, knowing
its time stamp, etc.... would be useful, independently it is CDOResource
or a different one.

>
>>
>> Besides, for EFS, it seems that CDO can't escape from dealing with
>> streams, at least if we want to have a robust integration (I hate
>> having unsopportedOperationExceptions ;P) with EFS.
> I'm open for patches ;-)
> Could you give examples of these UOEs? I mean, who is throwing them, who
> is calling the throwing method, etc...
>

Again, I didn't explain. We could understand a CDOResource as IFileStore
and provide an implementation for IFileStore excepting for
openInputStream and openOutputStream, etc... throwing UOE instead.

I could copy, move, delete (CDO)FileStores, but I couldn't
openInput/Output streams.

That's what I meant that it is not robust integration, and probably an
unacceptable one, isn't ?.



>>
>> As you said, Eike, I think that CDO could do a great step if we get a
>> nice solution to make CDO compatible with streams usage. I hope to
>> better study the situation soon, to be able to give a point of view of
>> a possible solution (if any ;P).
> I prefer patches :P
>

I would also prefer it :D. I think that before starting to code, I need
to have a clear of the problem, and contrast the possible solution with
the experts ;).

Cheers !!!!
Adolfo

> Cheers
> /Eike
>
>>
>> Cheers,
>> Adolfo.
>>
>>>
>>>> But yes, we can talk when I have some time. :-)
>>>>
>>>>
>>>> Eike Stepper wrote:
>>>>>
>>>>>
>>>>> Eike Stepper schrieb:
>>>>>> Ed Merks schrieb:
>>>>>>> Eike,
>>>>>>>
>>>>>>> I keep imagining the creation of the input stream would establish
>>>>>>> the connection and would return in the stream itself, the
>>>>>>> information the resource would need to communicate directly with
>>>>>>> the server. No actual instance data would be transmitted through
>>>>>>> the stream, just " metadata" about the connection itself.
>>>>>>> Probably we should talk on skype when next I get a chance...
>>>>>>> Maybe on Friday...
>>>>>> Yes, as long as the stream-wrapping approach is only used to
>>>>>> integrate one framework with the other (as opposed to an existing
>>>>>> application)
>>>>> The difference is that the first only uses ("abuses") the stream as
>>>>> suitable carrier for stream-unrelated data while the latter would
>>>>> require the read() method to return something meaningful to an
>>>>> application.
>>>>>
>>>>>
>>>>>> I think it's worth discussing it. I'm always here. And have a
>>>>>> whole bunch of other things to discuss as well :P
>>>>>>
>>>>>> Cheers
>>>>>> /Eike
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Eike Stepper wrote:
>>>>>>>> Guys,
>>>>>>>>
>>>>>>>> I'm seeing that InputStream/OutputStream are very basic concpets
>>>>>>>> (unfortunately without proper interfaces) and complyance to them
>>>>>>>> would open a whole bunch of new possibilities to integrate with
>>>>>>>> other technologies (like EFS). The point is that I just don't
>>>>>>>> see *how* to make this work. The natures of a stream and a
>>>>>>>> stateful remote connection are so different. Could you imagine
>>>>>>>> to use the document-oriented paradigm of a word processor in the
>>>>>>>> same way as you work with fine grained objects in a
>>>>>>>> repository/database through a live connection?
>>>>>>>>
>>>>>>>> I ask myself what the client of a stream might expect from using
>>>>>>>> it. Most probably it will read from it until end of stream is
>>>>>>>> reached and do all its work while pulling form the stream or
>>>>>>>> shortly after finishing that. Then it usually closes the stream
>>>>>>>> and throws it away!
>>>>>>>>
>>>>>>>> Hit me but I don't see a way to remember the connection data in
>>>>>>>> the stream and make it avaliable to a stream based client after
>>>>>>>> that point in time. The only real alternative would be to do
>>>>>>>> everything so that the client will not have to need the
>>>>>>>> conncetion info later. For CDO that would mean i.e. pre-loading
>>>>>>>> the whole containment structure of a resource and disable the
>>>>>>>> remote updates that enable the distributed shared model features
>>>>>>>> of CDO. Maybe the latter problem could be addressed to some
>>>>>>>> degree for clients that have a little more knowledge about data
>>>>>>>> source than just "InputStream" (e.g. IFile with change
>>>>>>>> notification stuff).
>>>>>>>>
>>>>>>>> The OutputStream/commit analogy seems to be a bit less
>>>>>>>> unfortunate because currently CDO only offers an optimistic
>>>>>>>> locking strategy over the network. I wonder what the impact of
>>>>>>>> Bugzilla 247427 might be...
>>>>>>>>
>>>>>>>> 247427: Explicit locking
>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247427
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> /Eike
>>>>>>>>
>>>>>>>>
>>>>>>>> Ed Merks schrieb:
>>>>>>>>> Víctor,
>>>>>>>>>
>>>>>>>>> The resource factory is responsible for creating a resource
>>>>>>>>> that knows how to handle a specific type/form of content. The
>>>>>>>>> URIConverter/URIHandler is responsible for the communication
>>>>>>>>> between the resource and the backing store that supplies the
>>>>>>>>> bytes representing the content. I know that CDO maintains a
>>>>>>>>> live connection. But I could imagine
>>>>>>>>> URIConverter.createInputStream returning a small "dummy"
>>>>>>>>> stream that yields the information about the established
>>>>>>>>> connection which is then processed and used to prime the
>>>>>>>>> resource. Similarly the createOutputStream could be used to
>>>>>>>>> kick of the commit process. (But since I don't know the
>>>>>>>>> details, this is all very vague.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Víctor Roldán Betancort wrote:
>>>>>>>>>> Ed,
>>>>>>>>>>
>>>>>>>>>> I forgot something else. Would it be enough by just having the
>>>>>>>>>> ResourceFactory? Are the URIConverter/URIHandler indispensable
>>>>>>>>>> for this task? It seems to me these classes are kind of an
>>>>>>>>>> (more convenient?) alternative to the ResourceFactory for the
>>>>>>>>>> URI resolution task.
Re: [CDO] XMI models referencing elements stored in CDO [message #422918 is a reply to message #422917] Thu, 18 September 2008 16:32 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
Adolfo Sánchez-Barbudo Herrera schrieb:
> Hi Eike,
>
> Sorry for my bad "English", it's not the good it should be.
>
> Some comments:
>
>
>> No, because in CDO the granularity of commit/save is not the Resource
>> but rather EObject. Each CDOTransaction can modify aribrary objects
>> across all resource boundaries. All other CDOSessions in the wohle
>> network (including additional local ones) are notified for each
>> committed transaction. You can listen to their
>> CDOSessionInvalidationEvents:
>> | CDOSession session = ...;
>> session.addListener(*new *IListener()
>> {
>> *public **void *notifyEvent(IEvent event)
>> {
>> *if *(event *instanceof *CDOSessionInvalidationEvent)
>> {
>> CDOSessionInvalidationEvent e =
>> (CDOSessionInvalidationEvent)event;
>> Set<CDOIDAndVersion> dirtyOIDs = e.getDirtyOIDs();
>> *long *timeStamp = e.getTimeStamp();
>> ...
>> }
>> }
>> });|
>>
>>
>> Notice how you can access the time stamp of the server transaction
>> and the set of modified objects (through their IDs + versions).
>> Perhaps this can be handy when computing the set of affected
>> resources...
>>
>>
>
> I should probably have said "CDOResource's time stamp is not being
> managed". In EMF the own resource updates it when is loaded or saved.
> CDO implementation should do it when a transaction commits or
> something similar (Sorry again for not knowing CDO as well as I must
> know :( )
Oh sorry, I should have realized earlier! If you want to please put it
on our list ;-)

>
>>>
>>> However, AFAIK, CDO doesn't have
>>> CDOResourceSet/CDOUriConverter/CDOUriHandler (which deals with
>>> streams) to change in some point the way of doing such a thing
>>> (getting attributes for a resource persisted in a data base,).
>> I tend to believe that subtyping ResourceSet is a tabou (see earlier
>> discussion here inthe newsgroup). I didn't understand the rest of
>> your comment ;-(
>
> What I meant, is that we can't get info about attributes of a
> BD-persisted resource, if there is no specialization of one of those
> classes (CDOUriHandler would probably be more convenient, exception
> that it has the stream usage :( ).
Could you give examples of such attributes? I want to be sure what this
is all about.

>
>>>
>>> I think that everything that works fine for a XMI-persisted
>>> Resource, it would be *very* nice if it worked for a DB-persisted
>>> CDOResource.
>> In general I'd agree that everything that works fine for an EObject
>> should work in the same way for a CDOObject. I hesitate a bit to
>> generalize this statement to include the persistence mechanism as
>> well. Would you suggest that we handle things like
>> XMLResource.OPTION_PARSER_FEATURES as well? I mean, where do the
>> similarities stop and where do the differences start?
>> That said, we can certainly look at particular Resource features and
>> revisit our decisions ;-)
>
> That option doesn't seem to be candidate to support in CDO :D,
> especially when we are talking about a XMLResource -.-. Maybe we
> should focus on URIConverter/URIHandler API methods and Options. It
> seems that asking if a Resource URI exists, if it is read only
> Resource, knowing its time stamp, etc.... would be useful,
> independently it is CDOResource or a different one.
I think this should be easy to support. Can you file a Bugzilla and
describe which methods exactly you'd like to see supported?

>
>>
>>>
>>> Besides, for EFS, it seems that CDO can't escape from dealing with
>>> streams, at least if we want to have a robust integration (I hate
>>> having unsopportedOperationExceptions ;P) with EFS.
>> I'm open for patches ;-)
>> Could you give examples of these UOEs? I mean, who is throwing them,
>> who is calling the throwing method, etc...
>>
>
> Again, I didn't explain. We could understand a CDOResource as
> IFileStore and provide an implementation for IFileStore excepting for
> openInputStream and openOutputStream, etc... throwing UOE instead.
I see. I'd recomment to use a CDOView/CDOTransaction/CDOAudit as the
associated concept of IFileStore. They correspond to a particular
CDOSession which in turn correspnds to a whole repository.

>
> I could copy, move, delete (CDO)FileStores, but I couldn't
> openInput/Output streams.
>
> That's what I meant that it is not robust integration, and probably an
> unacceptable one, isn't ?.
I'm too new to EFS so that I can't really judge. Well, if I were looking
at a prototype... ;-)

>
>
>
>>>
>>> As you said, Eike, I think that CDO could do a great step if we get
>>> a nice solution to make CDO compatible with streams usage. I hope to
>>> better study the situation soon, to be able to give a point of view
>>> of a possible solution (if any ;P).
>> I prefer patches :P
>>
>
> I would also prefer it :D. I think that before starting to code, I
> need to have a clear of the problem, and contrast the possible
> solution with the experts ;).
Sure! We're all interested in good solutions and interesting discussions.

Cheers
/Eike

>
> Cheers !!!!
> Adolfo
>
>> Cheers
>> /Eike
>>
>>>
>>> Cheers,
>>> Adolfo.
>>>
>>>>
>>>>> But yes, we can talk when I have some time. :-)
>>>>>
>>>>>
>>>>> Eike Stepper wrote:
>>>>>>
>>>>>>
>>>>>> Eike Stepper schrieb:
>>>>>>> Ed Merks schrieb:
>>>>>>>> Eike,
>>>>>>>>
>>>>>>>> I keep imagining the creation of the input stream would
>>>>>>>> establish the connection and would return in the stream itself,
>>>>>>>> the information the resource would need to communicate directly
>>>>>>>> with the server. No actual instance data would be transmitted
>>>>>>>> through the stream, just " metadata" about the connection
>>>>>>>> itself. Probably we should talk on skype when next I get a
>>>>>>>> chance... Maybe on Friday...
>>>>>>> Yes, as long as the stream-wrapping approach is only used to
>>>>>>> integrate one framework with the other (as opposed to an
>>>>>>> existing application)
>>>>>> The difference is that the first only uses ("abuses") the stream
>>>>>> as suitable carrier for stream-unrelated data while the latter
>>>>>> would require the read() method to return something meaningful to
>>>>>> an application.
>>>>>>
>>>>>>
>>>>>>> I think it's worth discussing it. I'm always here. And have a
>>>>>>> whole bunch of other things to discuss as well :P
>>>>>>>
>>>>>>> Cheers
>>>>>>> /Eike
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Eike Stepper wrote:
>>>>>>>>> Guys,
>>>>>>>>>
>>>>>>>>> I'm seeing that InputStream/OutputStream are very basic
>>>>>>>>> concpets (unfortunately without proper interfaces) and
>>>>>>>>> complyance to them would open a whole bunch of new
>>>>>>>>> possibilities to integrate with other technologies (like EFS).
>>>>>>>>> The point is that I just don't see *how* to make this work.
>>>>>>>>> The natures of a stream and a stateful remote connection are
>>>>>>>>> so different. Could you imagine to use the document-oriented
>>>>>>>>> paradigm of a word processor in the same way as you work with
>>>>>>>>> fine grained objects in a repository/database through a live
>>>>>>>>> connection?
>>>>>>>>>
>>>>>>>>> I ask myself what the client of a stream might expect from
>>>>>>>>> using it. Most probably it will read from it until end of
>>>>>>>>> stream is reached and do all its work while pulling form the
>>>>>>>>> stream or shortly after finishing that. Then it usually closes
>>>>>>>>> the stream and throws it away!
>>>>>>>>>
>>>>>>>>> Hit me but I don't see a way to remember the connection data
>>>>>>>>> in the stream and make it avaliable to a stream based client
>>>>>>>>> after that point in time. The only real alternative would be
>>>>>>>>> to do everything so that the client will not have to need the
>>>>>>>>> conncetion info later. For CDO that would mean i.e.
>>>>>>>>> pre-loading the whole containment structure of a resource and
>>>>>>>>> disable the remote updates that enable the distributed shared
>>>>>>>>> model features of CDO. Maybe the latter problem could be
>>>>>>>>> addressed to some degree for clients that have a little more
>>>>>>>>> knowledge about data source than just "InputStream" (e.g.
>>>>>>>>> IFile with change notification stuff).
>>>>>>>>>
>>>>>>>>> The OutputStream/commit analogy seems to be a bit less
>>>>>>>>> unfortunate because currently CDO only offers an optimistic
>>>>>>>>> locking strategy over the network. I wonder what the impact of
>>>>>>>>> Bugzilla 247427 might be...
>>>>>>>>>
>>>>>>>>> 247427: Explicit locking
>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247427
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> /Eike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ed Merks schrieb:
>>>>>>>>>> Víctor,
>>>>>>>>>>
>>>>>>>>>> The resource factory is responsible for creating a resource
>>>>>>>>>> that knows how to handle a specific type/form of content.
>>>>>>>>>> The URIConverter/URIHandler is responsible for the
>>>>>>>>>> communication between the resource and the backing store that
>>>>>>>>>> supplies the bytes representing the content. I know that CDO
>>>>>>>>>> maintains a live connection. But I could imagine
>>>>>>>>>> URIConverter.createInputStream returning a small "dummy"
>>>>>>>>>> stream that yields the information about the established
>>>>>>>>>> connection which is then processed and used to prime the
>>>>>>>>>> resource. Similarly the createOutputStream could be used to
>>>>>>>>>> kick of the commit process. (But since I don't know the
>>>>>>>>>> details, this is all very vague.)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Víctor Roldán Betancort wrote:
>>>>>>>>>>> Ed,
>>>>>>>>>>>
>>>>>>>>>>> I forgot something else. Would it be enough by just having
>>>>>>>>>>> the ResourceFactory? Are the URIConverter/URIHandler
>>>>>>>>>>> indispensable for this task? It seems to me these classes
>>>>>>>>>>> are kind of an (more convenient?) alternative to the
>>>>>>>>>>> ResourceFactory for the URI resolution task.


Re: [CDO] XMI models referencing elements stored in CDO [message #422919 is a reply to message #422918] Thu, 18 September 2008 18:17 Go to previous messageGo to next message
Adolfo Sanchez-Barbudo Herrera is currently offline Adolfo Sanchez-Barbudo HerreraFriend
Messages: 260
Registered: July 2009
Senior Member
> Oh sorry, I should have realized earlier! If you want to please put it
> on our list ;-)

I'll raise a bugzilla request enhancement.

> Could you give examples of such attributes? I want to be sure what this
> is all about.

Here you have an example of use, which is very useful to know if my
on-memory resource is synchronized (with the persisted model) or it is not.

public static boolean isSynchronizedResource(Resource resource) {

ResourceSet resourceSet = resource.getResourceSet();
URI resourceURI = resource.getURI();
long resourceTimeStamp = resource.getTimeStamp();

Map<String,?> attributes =
resourceSet.getURIConverter().getAttributes(resourceURI, TIME_STAMP_OPTION);

Long actualTimeStamp = (Long)
attributes.get(URIConverter.ATTRIBUTE_TIME_STAMP);
return (resourceTimeStamp == actualTimeStamp) ? true : false;
}

This pretty example works fine with XMI resources (even remote ones via
EFS). It is not showed here, but the default URIConverter of a
ResourceSetImpl delegates to the associated URIHandlers to obtain the
associated attributes of a resourceURI.

So if CDO has a proper UriHandler implementation, and I register that
UriHandler to my resourceSets, I could access to such an interesting
attribute independently it's a XMIResource or a CDO one.

The above utility is fantastic, if you are going to take any kind of
action on a Resource and you want to ensure that it is synchronized with
the "persisted version" (and you don't want to worry about any external
modifications before taking that action).

More interesting attributes:
- URIConverter.ATTRIBUTE_READ_ONLY
- URIConverter.ATTRIBUTE_ARCHIVE/DIRECTORY ¿? => if EFS implementation
is finally provided.


>>
>>>>
>>>> I think that everything that works fine for a XMI-persisted
>>>> Resource, it would be *very* nice if it worked for a DB-persisted
>>>> CDOResource.
>>> In general I'd agree that everything that works fine for an EObject
>>> should work in the same way for a CDOObject. I hesitate a bit to
>>> generalize this statement to include the persistence mechanism as
>>> well. Would you suggest that we handle things like
>>> XMLResource.OPTION_PARSER_FEATURES as well? I mean, where do the
>>> similarities stop and where do the differences start?
>>> That said, we can certainly look at particular Resource features and
>>> revisit our decisions ;-)
>>
>> That option doesn't seem to be candidate to support in CDO :D,
>> especially when we are talking about a XMLResource -.-. Maybe we
>> should focus on URIConverter/URIHandler API methods and Options. It
>> seems that asking if a Resource URI exists, if it is read only
>> Resource, knowing its time stamp, etc.... would be useful,
>> independently it is CDOResource or a different one.
> I think this should be easy to support. Can you file a Bugzilla and
> describe which methods exactly you'd like to see supported?

Ok, I'll raise one but I think that ideally all the URIHandler methods
should be implemented. Again, we'll have the problem of the streams :(

>
>>
>>>
>>>>
>>>> Besides, for EFS, it seems that CDO can't escape from dealing with
>>>> streams, at least if we want to have a robust integration (I hate
>>>> having unsopportedOperationExceptions ;P) with EFS.
>>> I'm open for patches ;-)
>>> Could you give examples of these UOEs? I mean, who is throwing them,
>>> who is calling the throwing method, etc...
>>>
>>
>> Again, I didn't explain. We could understand a CDOResource as
>> IFileStore and provide an implementation for IFileStore excepting for
>> openInputStream and openOutputStream, etc... throwing UOE instead.
> I see. I'd recomment to use a CDOView/CDOTransaction/CDOAudit as the
> associated concept of IFileStore. They correspond to a particular
> CDOSession which in turn correspnds to a whole repository.

I'll write down the suggestion ;), but I'll have to deep on that CDO
concepts to agree or disagree.

>
>>
>> I could copy, move, delete (CDO)FileStores, but I couldn't
>> openInput/Output streams.
>>
>> That's what I meant that it is not robust integration, and probably an
>> unacceptable one, isn't ?.
> I'm too new to EFS so that I can't really judge. Well, if I were looking
> at a prototype... ;-)

Well I know a little bit about EFS, you know about CDO. I hope we can
find a nice and reasonable solution ;)

Cheers,
Adolfo.

>
>>
>>
>>
>>>>
>>>> As you said, Eike, I think that CDO could do a great step if we get
>>>> a nice solution to make CDO compatible with streams usage. I hope to
>>>> better study the situation soon, to be able to give a point of view
>>>> of a possible solution (if any ;P).
>>> I prefer patches :P
>>>
>>
>> I would also prefer it :D. I think that before starting to code, I
>> need to have a clear of the problem, and contrast the possible
>> solution with the experts ;).
> Sure! We're all interested in good solutions and interesting discussions.
>
> Cheers
> /Eike
>
>>
>> Cheers !!!!
>> Adolfo
>>
>>> Cheers
>>> /Eike
>>>
>>>>
>>>> Cheers,
>>>> Adolfo.
>>>>
>>>>>
>>>>>> But yes, we can talk when I have some time. :-)
>>>>>>
>>>>>>
>>>>>> Eike Stepper wrote:
>>>>>>>
>>>>>>>
>>>>>>> Eike Stepper schrieb:
>>>>>>>> Ed Merks schrieb:
>>>>>>>>> Eike,
>>>>>>>>>
>>>>>>>>> I keep imagining the creation of the input stream would
>>>>>>>>> establish the connection and would return in the stream itself,
>>>>>>>>> the information the resource would need to communicate directly
>>>>>>>>> with the server. No actual instance data would be transmitted
>>>>>>>>> through the stream, just " metadata" about the connection
>>>>>>>>> itself. Probably we should talk on skype when next I get a
>>>>>>>>> chance... Maybe on Friday...
>>>>>>>> Yes, as long as the stream-wrapping approach is only used to
>>>>>>>> integrate one framework with the other (as opposed to an
>>>>>>>> existing application)
>>>>>>> The difference is that the first only uses ("abuses") the stream
>>>>>>> as suitable carrier for stream-unrelated data while the latter
>>>>>>> would require the read() method to return something meaningful to
>>>>>>> an application.
>>>>>>>
>>>>>>>
>>>>>>>> I think it's worth discussing it. I'm always here. And have a
>>>>>>>> whole bunch of other things to discuss as well :P
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> /Eike
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Eike Stepper wrote:
>>>>>>>>>> Guys,
>>>>>>>>>>
>>>>>>>>>> I'm seeing that InputStream/OutputStream are very basic
>>>>>>>>>> concpets (unfortunately without proper interfaces) and
>>>>>>>>>> complyance to them would open a whole bunch of new
>>>>>>>>>> possibilities to integrate with other technologies (like EFS).
>>>>>>>>>> The point is that I just don't see *how* to make this work.
>>>>>>>>>> The natures of a stream and a stateful remote connection are
>>>>>>>>>> so different. Could you imagine to use the document-oriented
>>>>>>>>>> paradigm of a word processor in the same way as you work with
>>>>>>>>>> fine grained objects in a repository/database through a live
>>>>>>>>>> connection?
>>>>>>>>>>
>>>>>>>>>> I ask myself what the client of a stream might expect from
>>>>>>>>>> using it. Most probably it will read from it until end of
>>>>>>>>>> stream is reached and do all its work while pulling form the
>>>>>>>>>> stream or shortly after finishing that. Then it usually closes
>>>>>>>>>> the stream and throws it away!
>>>>>>>>>>
>>>>>>>>>> Hit me but I don't see a way to remember the connection data
>>>>>>>>>> in the stream and make it avaliable to a stream based client
>>>>>>>>>> after that point in time. The only real alternative would be
>>>>>>>>>> to do everything so that the client will not have to need the
>>>>>>>>>> conncetion info later. For CDO that would mean i.e.
>>>>>>>>>> pre-loading the whole containment structure of a resource and
>>>>>>>>>> disable the remote updates that enable the distributed shared
>>>>>>>>>> model features of CDO. Maybe the latter problem could be
>>>>>>>>>> addressed to some degree for clients that have a little more
>>>>>>>>>> knowledge about data source than just "InputStream" (e.g.
>>>>>>>>>> IFile with change notification stuff).
>>>>>>>>>>
>>>>>>>>>> The OutputStream/commit analogy seems to be a bit less
>>>>>>>>>> unfortunate because currently CDO only offers an optimistic
>>>>>>>>>> locking strategy over the network. I wonder what the impact of
>>>>>>>>>> Bugzilla 247427 might be...
>>>>>>>>>>
>>>>>>>>>> 247427: Explicit locking
>>>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247427
>>>>>>>>>>
>>>>>>>>>> Cheers
>>>>>>>>>> /Eike
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ed Merks schrieb:
>>>>>>>>>>> Víctor,
>>>>>>>>>>>
>>>>>>>>>>> The resource factory is responsible for creating a resource
>>>>>>>>>>> that knows how to handle a specific type/form of content.
>>>>>>>>>>> The URIConverter/URIHandler is responsible for the
>>>>>>>>>>> communication between the resource and the backing store that
>>>>>>>>>>> supplies the bytes representing the content. I know that CDO
>>>>>>>>>>> maintains a live connection. But I could imagine
>>>>>>>>>>> URIConverter.createInputStream returning a small "dummy"
>>>>>>>>>>> stream that yields the information about the established
>>>>>>>>>>> connection which is then processed and used to prime the
>>>>>>>>>>> resource. Similarly the createOutputStream could be used to
>>>>>>>>>>> kick of the commit process. (But since I don't know the
>>>>>>>>>>> details, this is all very vague.)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Víctor Roldán Betancort wrote:
>>>>>>>>>>>> Ed,
>>>>>>>>>>>>
>>>>>>>>>>>> I forgot something else. Would it be enough by just having
>>>>>>>>>>>> the ResourceFactory? Are the URIConverter/URIHandler
>>>>>>>>>>>> indispensable for this task? It seems to me these classes
>>>>>>>>>>>> are kind of an (more convenient?) alternative to the
>>>>>>>>>>>> ResourceFactory for the URI resolution task.
Re: [CDO] XMI models referencing elements stored in CDO [message #422930 is a reply to message #422875] Fri, 19 September 2008 02:09 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
What do you think about using OutputStream/INputStream to export/import XMI
format ?

With options arguments we could :

- Export/import one resource (with or without containment)
- Export/import on object(with or without containment)

With this layer we could talk to anybody else!! update our objects... etc.

What do you think ? I'm getting excited!! :-)
Simon



"Eike Stepper" <stepper@esc-net.de> a
Re: [CDO] XMI models referencing elements stored in CDO [message #422931 is a reply to message #422930] Fri, 19 September 2008 05:58 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6464
Registered: July 2009
Senior Member
Simon McDuff schrieb:
> What do you think about using OutputStream/INputStream to export/import XMI
> format ?
>
> With options arguments we could :
>
> - Export/import one resource (with or without containment)
> - Export/import on object(with or without containment)
>
> With this layer we could talk to anybody else!! update our objects... etc.
>
> What do you think ? I'm getting excited!! :-)
>
Hehe, I would never be so stupid to decelerate your enthusiasm :P
So far it used to create cool solutions!

I suggest to continue the discussion here (and maybe adjust the summary
to reflect the broader scope):

247873: Getting information of a CDO URI.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=247873

Cheers
/Eike

> Simon
>
>
>
> "Eike Stepper" <stepper@esc-net.de> a écrit dans le message de news:
> garn59$42c$1@build.eclipse.org...
>
>> Guys,
>>
>> I'm seeing that InputStream/OutputStream are very basic concpets
>> (unfortunately without proper interfaces) and complyance to them would
>> open a whole bunch of new possibilities to integrate with other
>> technologies (like EFS). The point is that I just don't see *how* to make
>> this work. The natures of a stream and a stateful remote connection are so
>> different. Could you imagine to use the document-oriented paradigm of a
>> word processor in the same way as you work with fine grained objects in a
>> repository/database through a live connection?
>>
>> I ask myself what the client of a stream might expect from using it. Most
>> probably it will read from it until end of stream is reached and do all
>> its work while pulling form the stream or shortly after finishing that.
>> Then it usually closes the stream and throws it away!
>>
>> Hit me but I don't see a way to remember the connection data in the stream
>> and make it avaliable to a stream based client after that point in time.
>> The only real alternative would be to do everything so that the client
>> will not have to need the conncetion info later. For CDO that would mean
>> i.e. pre-loading the whole containment structure of a resource and disable
>> the remote updates that enable the distributed shared model features of
>> CDO. Maybe the latter problem could be addressed to some degree for
>> clients that have a little more knowledge about data source than just
>> "InputStream" (e.g. IFile with change notification stuff).
>>
>> The OutputStream/commit analogy seems to be a bit less unfortunate because
>> currently CDO only offers an optimistic locking strategy over the network.
>> I wonder what the impact of Bugzilla 247427 might be...
>>
>> 247427: Explicit locking
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=247427
>>
>> Cheers
>> /Eike
>>
>>
>> Ed Merks schrieb:
>>
>>> Víctor,
>>>
>>> The resource factory is responsible for creating a resource that knows
>>> how to handle a specific type/form of content. The
>>> URIConverter/URIHandler is responsible for the communication between the
>>> resource and the backing store that supplies the bytes representing the
>>> content. I know that CDO maintains a live connection. But I could
>>> imagine URIConverter.createInputStream returning a small "dummy" stream
>>> that yields the information about the established connection which is
>>> then processed and used to prime the resource. Similarly the
>>> createOutputStream could be used to kick of the commit process. (But
>>> since I don't know the details, this is all very vague.)
>>>
>>>
>>> Víctor Roldán Betancort wrote:
>>>
>>>> Ed,
>>>>
>>>> I forgot something else. Would it be enough by just having the
>>>> ResourceFactory? Are the URIConverter/URIHandler indispensable for this
>>>> task? It seems to me these classes are kind of an (more convenient?)
>>>> alternative to the ResourceFactory for the URI resolution task.
>>>>
>
>
>


Previous Topic:CDO Adding a new resource
Next Topic:[CDO] Objectivity as CDO database
Goto Forum:
  


Current Time: Mon Jan 20 15:15:17 GMT 2020

Powered by FUDForum. Page generated in 0.12541 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top