[jr3] Wrapped intelligent objects

[Johann Sorel <jo...@geomatys.com>]

Hi,

Sorry to kick in the discussion, I made an implementation of JCR last 
septembre for our geographic information system.
While doing it I found one annoying point in the current specification.
If you can take a minute to read the following.

As you know all, jcr is designed to manage datas of basic types : 
double, string, boolean, stream ...and so on.
That solves most needs for any kind of storage system. But in some cases 
like ours we also store what I would
call "intelligent" objects, like mathematic functions, coordinate 
systems , objects that have more then just properties
fields, they have capabilities (methods to make it simple).

I believe most of you have already made a bit of Swing before, there is 
a class MutableTreeNode with a getUserObject()
method used to retrieve the real object hiden behind the node.

My suggestion would be to have a similar approach in JCR. something like 
unwrap() to acces the intelligent object on the node
if there is one of course.

JCR is great but infortunatly we seen that we can do nothing else then 
copying informations, make statistics or search based on properties.
Which is mostly useless for us. We need to be able to access the objects 
hidden behind the nodes,
objects that follow whatever else specification (GeoAPI specification in 
our case) so that we can work with them.

I hope you see the point here.

thanks



Johann sorel
Geomatys

Re: [jr3] Wrapped intelligent objects

[Alexander Klimetschek <ak...@day.com>]

On Thu, Feb 18, 2010 at 09:45, sorel <jo...@geomatys.fr> wrote:
> Keep in mind that the only thing you can rely on from outside are the
> specification
> interfaces. If you force a application to rely directly on jackrabbit to do
> it's work then
> you misunderstand the purpose of the JCR specification.
>
> ...
>
> So here is my question : how do you get acces to object following the GeoAPI
> standard
> through the JCR specification (not jackrabbit) ? I don't see any.

Jackrabbit OCM only relies on the JCR API. There are also other JCR
OCM frameworks such as jcrom [2], which also works generically on top
of the JCR API. (And it is about being moved/merged to Jackrabbit, but
just for project management reasons [3]).

[1] http://jackrabbit.apache.org/jackrabbit-ocm.html
[2] http://code.google.com/p/jcrom/
[3] http://www.mail-archive.com/dev@jackrabbit.apache.org/msg19253.html

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: [jr3] Wrapped intelligent objects

[sorel <jo...@geomatys.fr>]

Justin Edelson wrote:
>>> Did you try Object Content Mapping (OCM) with JCR (eg. Jackrabbit OCM)?
>>> In the end, the objects you want to store have fields that boil down
>>> to the basic properties (and if sth doesn't fit well, there is always
>>> string, which can be searched). Real object databases would be close
>>> to what you have in mind, but they always have the advantage that the
>>> data and fields/properties are not very visible, ie. there are no
>>> generic, standardized ways to look at the data, independent from the
>>> specific programming language they are designed for.
>>>   
>>>       
>> We only use jackrabbit JCR commun module, and we don't intent to use any
>> more
>> module or we will lose all our cache structure (duplicate would be more
>> extact).
>> The problem is not the storage anyway.
>>     
>
> I'm not sure I understand what you're saying here about your cache
> structure, but I agree with Alex - the "intelligent object" problem you
> describe above seems to solved by OCM.
>
>   
>> let's take an exemple :
>>
>> Imagine Liferay for exemple, 2 companies manage somehow to expose
>> repositories
>> in liferay by adding each one a plugin. thoses repositories are now
>> visible by any portlet in liferay. Each
>> repository have geographic datas clearly defined by a well knowned Node
>> type.
>>
>> Now you add a mapping jsf portlet made by a third company that can
>> access thoses repository and can render
>> any object that match this node type. problem is, the attributs are not
>> enough to render a map, he needs acces to
>> the hidden object, objects that follow another specification.
>> But unfortunatly he can't since not method on the JCR node interface can
>> give him this object.
>>     
>
> And why do you think you can't do this with OCM?
>
> The mapping portlet would just need to use the ObjectContentManager to
> get an instance of your custom class. The only difference is that
> instead of the Node having a "hidden" instance of a custom class, the
> portlet just gets an instance of the custom class. Which is actually
> simpler
The third application only knows the JSR-275 (JCR). it knows how
to speak to them whatever implementation they are (jackrabbit, 
exoplatform ...)
So he can't acces the ObjectContentManager which is specific to jackrabbit.

Keep in mind that the only thing you can rely on from outside are the 
specification
interfaces. If you force a application to rely directly on jackrabbit to 
do it's work then
you misunderstand the purpose of the JCR specification.


>> Using JCR is a bit like being in front of a no entrance bunker,
>> informations are exposed through a small perfectly formatted window.
>> The bunker has a big sign writen : "hospital", ho! great I'm a doctor, I
>> can talk my own language (specification) with them (100times more
>> efficient) but how do I get in ? there is no entrance.
>> I believe there is a need for this door otherwise JCR will be
>> incompatible with any other specification.
>>     
>
> I'm not sure what other specifications you're referring to here. Can you
> elaborate?
OGC = Open Geospatial Consortium. http://www.opengeospatial.org/

I have plenty, ISO 19107 (geometries), OGC GML (geographic markup language),
ISO 19105 referencing. ISO 19109 Feature ... and plenty others.
They are more then just specification, they are standards.

They have been translated in java interface in the OGC GeoAPI standard :
http://geoapi.sourceforge.net/

So here is my question : how do you get acces to object following the 
GeoAPI standard
through the JCR specification (not jackrabbit) ? I don't see any.


johann sorel

Re: [jr3] Wrapped intelligent objects

[Justin Edelson <ju...@gmail.com>]

On 2/17/10 5:51 PM, Johann Sorel wrote:
> Alexander Klimetschek wrote:
>> On Wed, Feb 17, 2010 at 21:58, Johann Sorel
>> <jo...@geomatys.com> wrote:
>>  
>>> Sorry to kick in the discussion, I made an implementation of JCR last
>>> septembre for our geographic information system.
>>> While doing it I found one annoying point in the current specification.
>>> If you can take a minute to read the following.
>>>
>>> As you know all, jcr is designed to manage datas of basic types :
>>> double,
>>> string, boolean, stream ...and so on.
>>> That solves most needs for any kind of storage system. But in some cases
>>> like ours we also store what I would
>>> call "intelligent" objects, like mathematic functions, coordinate
>>> systems ,
>>> objects that have more then just properties
>>> fields, they have capabilities (methods to make it simple).
>>>
>>> I believe most of you have already made a bit of Swing before, there
>>> is a
>>> class MutableTreeNode with a getUserObject()
>>> method used to retrieve the real object hiden behind the node.
>>>
>>> My suggestion would be to have a similar approach in JCR. something like
>>> unwrap() to acces the intelligent object on the node
>>> if there is one of course.
>>>
>>> JCR is great but infortunatly we seen that we can do nothing else then
>>> copying informations, make statistics or search based on properties.
>>> Which is mostly useless for us. We need to be able to access the objects
>>> hidden behind the nodes,
>>> objects that follow whatever else specification (GeoAPI specification
>>> in our
>>> case) so that we can work with them.
>>>
>>> I hope you see the point here.
>>>     
>>
>> Did you try Object Content Mapping (OCM) with JCR (eg. Jackrabbit OCM)?
>>
>> In the end, the objects you want to store have fields that boil down
>> to the basic properties (and if sth doesn't fit well, there is always
>> string, which can be searched). Real object databases would be close
>> to what you have in mind, but they always have the advantage that the
>> data and fields/properties are not very visible, ie. there are no
>> generic, standardized ways to look at the data, independent from the
>> specific programming language they are designed for.
>>   
> We only use jackrabbit JCR commun module, and we don't intent to use any
> more
> module or we will lose all our cache structure (duplicate would be more
> extact).
> The problem is not the storage anyway.

I'm not sure I understand what you're saying here about your cache
structure, but I agree with Alex - the "intelligent object" problem you
describe above seems to solved by OCM.

> 
> let's take an exemple :
> 
> Imagine Liferay for exemple, 2 companies manage somehow to expose
> repositories
> in liferay by adding each one a plugin. thoses repositories are now
> visible by any portlet in liferay. Each
> repository have geographic datas clearly defined by a well knowned Node
> type.
> 
> Now you add a mapping jsf portlet made by a third company that can
> access thoses repository and can render
> any object that match this node type. problem is, the attributs are not
> enough to render a map, he needs acces to
> the hidden object, objects that follow another specification.
> But unfortunatly he can't since not method on the JCR node interface can
> give him this object.

And why do you think you can't do this with OCM?

The mapping portlet would just need to use the ObjectContentManager to
get an instance of your custom class. The only difference is that
instead of the Node having a "hidden" instance of a custom class, the
portlet just gets an instance of the custom class. Which is actually
simpler.


> Using JCR is a bit like being in front of a no entrance bunker,
> informations are exposed through a small perfectly formatted window.
> The bunker has a big sign writen : "hospital", ho! great I'm a doctor, I
> can talk my own language (specification) with them (100times more
> efficient) but how do I get in ? there is no entrance.
> I believe there is a need for this door otherwise JCR will be
> incompatible with any other specification.

I'm not sure what other specifications you're referring to here. Can you
elaborate?

Justin

> 
> sorry if my english is not perfect.
> 
> johann sorel
> 
> 

Re: [jr3] Wrapped intelligent objects

[Johann Sorel <jo...@geomatys.com>]

Alexander Klimetschek wrote:
> On Wed, Feb 17, 2010 at 21:58, Johann Sorel <jo...@geomatys.com> wrote:
>   
>> Sorry to kick in the discussion, I made an implementation of JCR last
>> septembre for our geographic information system.
>> While doing it I found one annoying point in the current specification.
>> If you can take a minute to read the following.
>>
>> As you know all, jcr is designed to manage datas of basic types : double,
>> string, boolean, stream ...and so on.
>> That solves most needs for any kind of storage system. But in some cases
>> like ours we also store what I would
>> call "intelligent" objects, like mathematic functions, coordinate systems ,
>> objects that have more then just properties
>> fields, they have capabilities (methods to make it simple).
>>
>> I believe most of you have already made a bit of Swing before, there is a
>> class MutableTreeNode with a getUserObject()
>> method used to retrieve the real object hiden behind the node.
>>
>> My suggestion would be to have a similar approach in JCR. something like
>> unwrap() to acces the intelligent object on the node
>> if there is one of course.
>>
>> JCR is great but infortunatly we seen that we can do nothing else then
>> copying informations, make statistics or search based on properties.
>> Which is mostly useless for us. We need to be able to access the objects
>> hidden behind the nodes,
>> objects that follow whatever else specification (GeoAPI specification in our
>> case) so that we can work with them.
>>
>> I hope you see the point here.
>>     
>
> Did you try Object Content Mapping (OCM) with JCR (eg. Jackrabbit OCM)?
>
> In the end, the objects you want to store have fields that boil down
> to the basic properties (and if sth doesn't fit well, there is always
> string, which can be searched). Real object databases would be close
> to what you have in mind, but they always have the advantage that the
> data and fields/properties are not very visible, ie. there are no
> generic, standardized ways to look at the data, independent from the
> specific programming language they are designed for.
>   
We only use jackrabbit JCR commun module, and we don't intent to use any 
more
module or we will lose all our cache structure (duplicate would be more 
extact).
The problem is not the storage anyway.

let's take an exemple :

Imagine Liferay for exemple, 2 companies manage somehow to expose 
repositories
in liferay by adding each one a plugin. thoses repositories are now 
visible by any portlet in liferay. Each
repository have geographic datas clearly defined by a well knowned Node 
type.

Now you add a mapping jsf portlet made by a third company that can 
access thoses repository and can render
any object that match this node type. problem is, the attributs are not 
enough to render a map, he needs acces to
the hidden object, objects that follow another specification.
But unfortunatly he can't since not method on the JCR node interface can 
give him this object.

Using JCR is a bit like being in front of a no entrance bunker, 
informations are exposed through a small perfectly formatted window.
The bunker has a big sign writen : "hospital", ho! great I'm a doctor, I 
can talk my own language (specification) with them (100times more 
efficient) but how do I get in ? there is no entrance.
I believe there is a need for this door otherwise JCR will be 
incompatible with any other specification.

sorry if my english is not perfect.

johann sorel

Re: [jr3] Wrapped intelligent objects

[Alexander Klimetschek <ak...@day.com>]

On Wed, Feb 17, 2010 at 22:57, Alexander Klimetschek <ak...@day.com> wrote:
> ...Real object databases would be close
> to what you have in mind, but they always have the advantage ...

Disadvantage, of course.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com

Re: [jr3] Wrapped intelligent objects

[Alexander Klimetschek <ak...@day.com>]

On Wed, Feb 17, 2010 at 21:58, Johann Sorel <jo...@geomatys.com> wrote:
> Sorry to kick in the discussion, I made an implementation of JCR last
> septembre for our geographic information system.
> While doing it I found one annoying point in the current specification.
> If you can take a minute to read the following.
>
> As you know all, jcr is designed to manage datas of basic types : double,
> string, boolean, stream ...and so on.
> That solves most needs for any kind of storage system. But in some cases
> like ours we also store what I would
> call "intelligent" objects, like mathematic functions, coordinate systems ,
> objects that have more then just properties
> fields, they have capabilities (methods to make it simple).
>
> I believe most of you have already made a bit of Swing before, there is a
> class MutableTreeNode with a getUserObject()
> method used to retrieve the real object hiden behind the node.
>
> My suggestion would be to have a similar approach in JCR. something like
> unwrap() to acces the intelligent object on the node
> if there is one of course.
>
> JCR is great but infortunatly we seen that we can do nothing else then
> copying informations, make statistics or search based on properties.
> Which is mostly useless for us. We need to be able to access the objects
> hidden behind the nodes,
> objects that follow whatever else specification (GeoAPI specification in our
> case) so that we can work with them.
>
> I hope you see the point here.

Did you try Object Content Mapping (OCM) with JCR (eg. Jackrabbit OCM)?

In the end, the objects you want to store have fields that boil down
to the basic properties (and if sth doesn't fit well, there is always
string, which can be searched). Real object databases would be close
to what you have in mind, but they always have the advantage that the
data and fields/properties are not very visible, ie. there are no
generic, standardized ways to look at the data, independent from the
specific programming language they are designed for.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com