Alfresco + Jackrabbit

[Frans Thamura <fl...@meruvian.com>]

anyone using Alfresco,

i got an email from John Newton, said that Jackrabbit is just for flat 
file, and bad solution for hiearchical data, which alfresco focus on

i see the structure of Alfresco is different

any input?

Frans

Re: Alfresco + Jackrabbit

[Stefan Guggisberg <st...@gmail.com>]

On 10/9/06, Frans Thamura <fl...@meruvian.com> wrote:
> anyone using Alfresco,
>
> i got an email from John Newton, said that Jackrabbit is just for flat
> file, and bad solution for hiearchical data, which alfresco focus on

can't believe that john said that...

well, on the other hand he probably just tries to make his product
look better ;-)

never mind, there's no reason whatsoever why jackrabbit would be
a "bad solution for hierarchical data".

cheers
stefan

>
> i see the structure of Alfresco is different
>
> any input?
>
> Frans
>

Re: Alfresco + Jackrabbit

[Serge Huber <sh...@jahia.com>]

Frans Thamura wrote:
> Serge Huber wrote:
>>
>> Well I looked at Alfresco a while back but for me the main difference 
>> was at the time :
>>
>> - Nodes in Alfresco seem more file-oriented (basically it's mostly 
>> configured for that type of usage)
>> - Nodes in Jackrabbit are quite general
>>
> +1
>
> alfresco using database to store meta, and jackrabbit using file,
I think you have misunderstood what I was saying. Alfresco's 
implementation is based on the JCR, so it is quite similar to 
Jackrabbit's. The difference is that by default configuration, 
Jackrabbit's repository is much more general, while Alfresco's is 
configured to store files. But they are both able to store data in a JCR 
compliant way.

I must say I'm not entirely convinced by hierarchical storage though, 
because more and more data querying is done through the query language, 
as personalization and searching become a good way to present relevant 
data to users. A tree is a projection of a graph, and it would be a 
shame to have only one possible "tree view" of the data. As I see the 
tree view, this is the "underlying" data model, used mostly by 
application writers, and then the actual data retrieval and processing 
can be done in multiple axis.

Regards,
  Serge Huber.

Re: Alfresco + Jackrabbit

[David Nuescheler <da...@gmail.com>]

> alfresco using database to store meta, and jackrabbit using file,
No, that's simply not true.

[ I appreciate that this is not the level of discussions we should
have on this list but, I just didn't want to leave this one unanswered
in the archives. ]

> John said this movement make Alfresco more high performance.
Knowing John, I seriously doubt that he would make a statement like
this.

> right now, I try to integrate alfresco with my Liferay, and my MVC
> framework (WebWork), but I see, develop from scratch using jackrabbit is
> better, because i dont need the hierarcical spaces
?! (speechless)

regards,
david

Re: Alfresco + Jackrabbit

[Frans Thamura <fl...@meruvian.com>]

Serge Huber wrote:
>
> Well I looked at Alfresco a while back but for me the main difference 
> was at the time :
>
> - Nodes in Alfresco seem more file-oriented (basically it's mostly 
> configured for that type of usage)
> - Nodes in Jackrabbit are quite general
>
+1

alfresco using database to store meta, and jackrabbit using file,

John said this movement make Alfresco more high performance.

right now, I try to integrate alfresco with my Liferay, and my MVC 
framework (WebWork), but I see, develop from scratch using jackrabbit is 
better, because i dont need the hierarcical spaces

FRans

Re: Alfresco + Jackrabbit

[Serge Huber <sh...@jahia.com>]

David Nuescheler wrote:
> Hi Robert,
>
>> Actually one thing that I find really interesting about Alfresco - in
>> case anyone wants to implement it as an add-on to Jackrabbit - is the
>> CIFS layer which supposedly allows good access to the server (as a
>> document server) from Windows clients.  I would imagine that using
>> the jCIFS library it would
>> be possible to write something similar for a more generic JSR-170
>> provider...
> I think this would be a good idea too, as a matter of fact we already
> looked into the feasibility of something like that and it seems to work
> just fine. Some random access performance drawbacks if we want
> to keep it strictly bound to the JCR API.
>
> jCIFS though is a CIFS client, right? At least I have not found a CIFS
> server other than Starlasoft's / Alfresco's?
> Am I looking in the wrong place?
Well the other question is the relationship between Starlasoft and 
Alfresco, as the developer that is behind Starlasoft is on Alfresco's 
payroll. What is not entirely clear is if the product on Starlasoft will 
continue to evolve or if JLAN will become an integral part of Alfresco.

The license of JLAN inside Alfresco is Mozilla-based, with a strong 
advertisement clause. But the advertisement clause concerns mostly GUIs, 
and how does it apply to server-side libraries ? If JLAN is used as a 
CIFS server for a Jackrabbit repository, where do you (and do you need 
to ?) advertise the Alfresco copyrights, etc ?
>
>> Having tried mapping a WeDAV
>> location as a network drive I can say that it really doesn't work in a
>> usable fashion.
> Really? So far I experienced a generally suboptimal perfomance
> but it works just as well as CIFS for me, both on MacOSX and Windows.
> What issues did you encounter?
Our experience with the WebDAV client on Windows has been nothing short 
of horrible : two many buggy DLLs out there (see 
http://www.greenbytes.de/tech/webdav/webfolder-client-list.html for a 
detailed list of the bugs and implementations) and they all behave 
differently. Caching is erratic, internationalisation is very poor (some 
operations like renaming a directory using non ISO8859-1 chars are not 
even sent out to the server depending on the version of the DLL !). My 
impression is that Microsoft does not view the WebDAV client as 
important, and therefore doesn't really make a big effort to maintain it.

CIFS on the other hand is the main file-sharing system on Windows 
system, and is actively developed and maintained by Microsoft. Of course 
this also means that they can change the protocol and implementation as 
they see fit, which is a problem for libraries like JLAN that must 
constantly keep up.

One idea that would be interesting would be to develop a "custom" open 
source "file-system" driver for Windows, that could use a transport such 
as WebDAV. There are closed-source solutions like Xythos Drive that 
already offer this, but having an open source one might be interesting. 
The good side about having such an implementation is that it could 
evolve seperately to Windows implementations of WebDAV. The bad side is 
that it's a lot of Windows-specific work and might be tedious. But there 
are success stories such as TortoiseCVS and TortoiseSVN, they just lack 
the mapping possibility.

The ideal open source configuration as I see it for file repositories :
- Strongly integrated open source client on Windows (offering the 
possibility to control versions, searches, check-in/check-out, locking, 
etc...).CIFS and the default WebDAV Windows client don't offer these 
features.
- JCR backends such as Jackrabbit.

Anyway, just some food for thought :)
cheers,
  Serge...

Re: Alfresco + Jackrabbit

["Robert r. Sanders" <ro...@ipov.net>]

Julian Reschke wrote:
> Robert r. Sanders schrieb:
>>>> Having tried mapping a WeDAV
>>>> location as a network drive I can say that it really doesn't work in a
>>>> usable fashion.
>>> Really? So far I experienced a generally suboptimal perfomance
>>> but it works just as well as CIFS for me, both on MacOSX and Windows.
>>> What issues did you encounter?
>> We tried Win2k client machines connecting to a Subversion server set 
>> to auto-version.  Opening a "web folder" worked ok; but trying to map 
>> that to a drive letter seemed to result in all sorts of issues, one 
>> of which I believe was an infinite loop in the login prompt.  Its 
>> been over a year, so the details have gotten kind of fuzzy.  Anyway, 
>> we were trying to use non-WebDAV aware programs (e.g. Flash, Wave 
>> file editors, etc...) and this also seemed to often result in 
>> zero-byte files being stored on the server.  Maybe a different 
>> combination on the server-side would have fixed the issue, I can't say.
>
> Well. If programs act suboptimal when presented with a JCR server 
> mapped to a drive letter through WebDAV, why do you think they'll work 
> any better with a JCR server mapped to a drive letter through CIFS? 
> It's only a different transport, but I don't think the main issues (*) 
> will go away.
>
> Best regards, Julian
>
>
>
> (*) such as: lots of temp files, no use of locking, creating new files 
> and moving them over instead of overwriting existing ones, causing 
> loss of metadata
First off as I said the server was actually not running a JCR 
implementation - it was running subversion (OS X was reported to work 
pretty well by one user who tried it with his notebook).  Secondly, my 
goal would be to "tune" the JCR server configuration to better handle 
the specific use cases (although this is of course speculative, but I 
think at least somewhat possible). Third, I suspect the big issue is 
that, as many people have found, the MS implementation of  WebDAV  
"drives' is pretty idiosyncratic, so although I have to admit I have not 
had a chance to test it, I would suspect something which exposed a CIFS 
interface would at least be easier to setup if nothing else.  Of course 
this is mostly speculative, but it meshes with my experience.

Re: Alfresco + Jackrabbit

[Julian Reschke <ju...@gmx.de>]

Robert r. Sanders schrieb:
>>> Having tried mapping a WeDAV
>>> location as a network drive I can say that it really doesn't work in a
>>> usable fashion.
>> Really? So far I experienced a generally suboptimal perfomance
>> but it works just as well as CIFS for me, both on MacOSX and Windows.
>> What issues did you encounter?
> We tried Win2k client machines connecting to a Subversion server set to 
> auto-version.  Opening a "web folder" worked ok; but trying to map that 
> to a drive letter seemed to result in all sorts of issues, one of which 
> I believe was an infinite loop in the login prompt.  Its been over a 
> year, so the details have gotten kind of fuzzy.  Anyway, we were trying 
> to use non-WebDAV aware programs (e.g. Flash, Wave file editors, etc...) 
> and this also seemed to often result in zero-byte files being stored on 
> the server.  Maybe a different combination on the server-side would have 
> fixed the issue, I can't say.

Well. If programs act suboptimal when presented with a JCR server mapped 
to a drive letter through WebDAV, why do you think they'll work any 
better with a JCR server mapped to a drive letter through CIFS? It's 
only a different transport, but I don't think the main issues (*) will 
go away.

Best regards, Julian



(*) such as: lots of temp files, no use of locking, creating new files 
and moving them over instead of overwriting existing ones, causing loss 
of metadata

Re: Alfresco + Jackrabbit

["Robert r. Sanders" <ro...@ipov.net>]

> I think this would be a good idea too, as a matter of fact we already
> looked into the feasibility of something like that and it seems to work
> just fine. Some random access performance drawbacks if we want
> to keep it strictly bound to the JCR API.
>
> jCIFS though is a CIFS client, right? At least I have not found a CIFS
> server other than Starlasoft's / Alfresco's?
> Am I looking in the wrong place?
Duh, I believe I had the two mixed up.  I don't know why; overly 
optimistic thinking I guess.


>
>> Having tried mapping a WeDAV
>> location as a network drive I can say that it really doesn't work in a
>> usable fashion.
> Really? So far I experienced a generally suboptimal perfomance
> but it works just as well as CIFS for me, both on MacOSX and Windows.
> What issues did you encounter?
We tried Win2k client machines connecting to a Subversion server set to 
auto-version.  Opening a "web folder" worked ok; but trying to map that 
to a drive letter seemed to result in all sorts of issues, one of which 
I believe was an infinite loop in the login prompt.  Its been over a 
year, so the details have gotten kind of fuzzy.  Anyway, we were trying 
to use non-WebDAV aware programs (e.g. Flash, Wave file editors, etc...) 
and this also seemed to often result in zero-byte files being stored on 
the server.  Maybe a different combination on the server-side would have 
fixed the issue, I can't say.



>
> regards,
> david

Re: Alfresco + Jackrabbit

[David Nuescheler <da...@gmail.com>]

Hi Robert,

> Actually one thing that I find really interesting about Alfresco - in
> case anyone wants to implement it as an add-on to Jackrabbit - is the
> CIFS layer which supposedly allows good access to the server (as a
> document server) from Windows clients.  I would imagine that using
> the jCIFS library it would
> be possible to write something similar for a more generic JSR-170
> provider...
I think this would be a good idea too, as a matter of fact we already
looked into the feasibility of something like that and it seems to work
just fine. Some random access performance drawbacks if we want
to keep it strictly bound to the JCR API.

jCIFS though is a CIFS client, right? At least I have not found a CIFS
server other than Starlasoft's / Alfresco's?
Am I looking in the wrong place?

> Having tried mapping a WeDAV
> location as a network drive I can say that it really doesn't work in a
> usable fashion.
Really? So far I experienced a generally suboptimal perfomance
but it works just as well as CIFS for me, both on MacOSX and Windows.
What issues did you encounter?

regards,
david

Re: Alfresco + Jackrabbit

[Frans Thamura <fl...@meruvian.com>]

Nicolas wrote:
> This is an excellent idea. Did you try using Alfresco's one? Is it 
> working
> well?
working well, but must be under intranet envionment

it CIFS implement SMB and add _A

if your server FRANS

so your alfresco CIFS become FRANS_A

there is a native .dll to make the alfrsco can become SMB file

JCIFS is better solution anyway.

Frans

Re: Alfresco + Jackrabbit

["Robert r. Sanders" <ro...@ipov.net>]

I must admit that I have not yet done so.  I am currently mostly lurking 
on this list.  I have an idea for an IT project using a content 
repository, but I have not had the time/resources to pursue it.

Nicolas wrote:
> This is an excellent idea. Did you try using Alfresco's one? Is it 
> working
> well?
>
> On 10/11/06, Robert r. Sanders <ro...@ipov.net> wrote:
>>
>> Actually one thing that I find really interesting about Alfresco - in
>> case anyone wants to implement it as an add-on to Jackrabbit - is the
>> CIFS layer which supposedly allows good access to the server (as a
>> document server) from Windows clients.  Having tried mapping a WeDAV
>> location as a network drive I can say that it really doesn't work in a
>> usable fashion.  I would imagine that using the jCIFS library it would
>> be possible to write something similar for a more generic JSR-170
>> provider... 

-- 
    Robert r. Sanders
    Chief Technologist
    iPOV
    (334) 821-5412
    www.ipov.net

Re: Alfresco + Jackrabbit

[Nicolas <nt...@gmail.com>]

 This is an excellent idea. Did you try using Alfresco's one? Is it working
well?

On 10/11/06, Robert r. Sanders <ro...@ipov.net> wrote:
>
> Actually one thing that I find really interesting about Alfresco - in
> case anyone wants to implement it as an add-on to Jackrabbit - is the
> CIFS layer which supposedly allows good access to the server (as a
> document server) from Windows clients.  Having tried mapping a WeDAV
> location as a network drive I can say that it really doesn't work in a
> usable fashion.  I would imagine that using the jCIFS library it would
> be possible to write something similar for a more generic JSR-170
> provider...
>
>
> Christophe Lombart wrote:
> > Another interesting comparaison is certainly the licence term which is
> > not very clear for the Alfresco product (at least for myself).
> >
> > On 10/9/06, Serge Huber <sh...@jahia.com> wrote:
> >>
> >> Well I looked at Alfresco a while back but for me the main difference
> >> was at the time :
> >>
> >> - Nodes in Alfresco seem more file-oriented (basically it's mostly
> >> configured for that type of usage)
> >> - Nodes in Jackrabbit are quite general
> >>
> >> But the two implementations are quite similar, except that Jackrabbit
> >> has decoupled the persistence implementation in a way that makes it
> easy
> >> to choose a back-end fitting your deployment. On the other hand
> Alfresco
> >> is database oriented, which will help with some issues such as
> >> transaction management, clustering, etc.
> >>
> >> Of course this is a very summarized view of the two technologies. There
> >> is a lot more to both, but it is not clear to me that one or the other
> >> would better fitted for large hierarchical data.
> >>
> >> One thing I have noted is that Alfreso is in full buzz mode right now
> :)
> >> So it would be nice to have a real-world comparison of the two techs.
> It
> >> seems to me that Alfresco is more EDM oriented than Jackrabbit though
> in
> >> terms of a product.
> >>
> >> And last time I did performance comparisons, nothing could beat
> >> Jackrabbit in terms of indexing speed, and the possibility to use
> >> file-based persistence was a interesting choice for "lighter"
> >> configurations that still need speed.
> >>
> >> For me the big issue with Jackrabbit is to scale it to really large
> >> datasets. I'd love to be able to say that Jackrabbit can scale to a
> >> cluster of 10-20 machines in cluster and managed hierarchical data of
> 20
> >> million nodes amounting to 100TB of data :)
> >>
> >> Regards,
> >>   Serge...
> >>
> >> Jukka Zitting wrote:
> >> > Hi,
> >> >
> >> > On 10/9/06, Alexandru Popescu <th...@gmail.com>
> >> > wrote:
> >> >> Other than this, I guess it may be oke to have different solutions
> >> for
> >> >> this spec implementation (in case you are referring to this).
> >> >
> >> > +1 In fact I'd be very interested in seeing some comparisons on the
> >> > various aspects of the different JCR implementations. There's a lot
> to
> >> > be learned from different approaches to the same problem.
> >> >
> >> > BR,
> >> >
> >> > Jukka Zitting
> >> >
> >>
> >>
> >
> >
>
>
> --
>     Robert r. Sanders
>     Chief Technologist
>     iPOV
>     (334) 821-5412
>     www.ipov.net
>
>


-- 
a+
Nico
my blog! http://www.deviant-abstraction.net !!

Re: Alfresco + Jackrabbit

["Robert r. Sanders" <ro...@ipov.net>]

Actually one thing that I find really interesting about Alfresco - in 
case anyone wants to implement it as an add-on to Jackrabbit - is the 
CIFS layer which supposedly allows good access to the server (as a 
document server) from Windows clients.  Having tried mapping a WeDAV 
location as a network drive I can say that it really doesn't work in a 
usable fashion.  I would imagine that using the jCIFS library it would 
be possible to write something similar for a more generic JSR-170 
provider...


Christophe Lombart wrote:
> Another interesting comparaison is certainly the licence term which is
> not very clear for the Alfresco product (at least for myself).
>
> On 10/9/06, Serge Huber <sh...@jahia.com> wrote:
>>
>> Well I looked at Alfresco a while back but for me the main difference
>> was at the time :
>>
>> - Nodes in Alfresco seem more file-oriented (basically it's mostly
>> configured for that type of usage)
>> - Nodes in Jackrabbit are quite general
>>
>> But the two implementations are quite similar, except that Jackrabbit
>> has decoupled the persistence implementation in a way that makes it easy
>> to choose a back-end fitting your deployment. On the other hand Alfresco
>> is database oriented, which will help with some issues such as
>> transaction management, clustering, etc.
>>
>> Of course this is a very summarized view of the two technologies. There
>> is a lot more to both, but it is not clear to me that one or the other
>> would better fitted for large hierarchical data.
>>
>> One thing I have noted is that Alfreso is in full buzz mode right now :)
>> So it would be nice to have a real-world comparison of the two techs. It
>> seems to me that Alfresco is more EDM oriented than Jackrabbit though in
>> terms of a product.
>>
>> And last time I did performance comparisons, nothing could beat
>> Jackrabbit in terms of indexing speed, and the possibility to use
>> file-based persistence was a interesting choice for "lighter"
>> configurations that still need speed.
>>
>> For me the big issue with Jackrabbit is to scale it to really large
>> datasets. I'd love to be able to say that Jackrabbit can scale to a
>> cluster of 10-20 machines in cluster and managed hierarchical data of 20
>> million nodes amounting to 100TB of data :)
>>
>> Regards,
>>   Serge...
>>
>> Jukka Zitting wrote:
>> > Hi,
>> >
>> > On 10/9/06, Alexandru Popescu <th...@gmail.com>
>> > wrote:
>> >> Other than this, I guess it may be oke to have different solutions 
>> for
>> >> this spec implementation (in case you are referring to this).
>> >
>> > +1 In fact I'd be very interested in seeing some comparisons on the
>> > various aspects of the different JCR implementations. There's a lot to
>> > be learned from different approaches to the same problem.
>> >
>> > BR,
>> >
>> > Jukka Zitting
>> >
>>
>>
>
>


-- 
    Robert r. Sanders
    Chief Technologist
    iPOV
    (334) 821-5412
    www.ipov.net

Re: Alfresco + Jackrabbit

[Frans Thamura <fl...@meruvian.com>]

Christophe Lombart wrote:
> Another interesting comparaison is certainly the licence term which is
> not very clear for the Alfresco product (at least for myself).
i got email from alfresco guy, because i recompile alfresco :) and i 
change the alfresco footer become my company copyright

now i just turn on my digital library with annoying alfresco statement.

and this happen after 1.3 :)


[logo] Supplied free of charge with no support 
<http://www.alfresco.com/services/support/communityterms/#support>, no 
certification 
<http://www.alfresco.com/services/support/communityterms/#certification>, 
no maintenance 
<http://www.alfresco.com/services/support/communityterms/#maintenance>, 
no warranty 
<http://www.alfresco.com/services/support/communityterms/#warranty> and 
no indemnity 
<http://www.alfresco.com/services/support/communityterms/#indemnity> by 
Alfresco <http://www.alfresco.com> or its Certified Partners 
<http://www.alfresco.com/partners/>. Click here for support 
<http://www.alfresco.com/services/support/>. Alfresco Software Inc. © 
2005-2006 All rights reserved.

Re: Alfresco + Jackrabbit

[Christophe Lombart <ch...@gmail.com>]

Another interesting comparaison is certainly the licence term which is
not very clear for the Alfresco product (at least for myself).

On 10/9/06, Serge Huber <sh...@jahia.com> wrote:
>
> Well I looked at Alfresco a while back but for me the main difference
> was at the time :
>
> - Nodes in Alfresco seem more file-oriented (basically it's mostly
> configured for that type of usage)
> - Nodes in Jackrabbit are quite general
>
> But the two implementations are quite similar, except that Jackrabbit
> has decoupled the persistence implementation in a way that makes it easy
> to choose a back-end fitting your deployment. On the other hand Alfresco
> is database oriented, which will help with some issues such as
> transaction management, clustering, etc.
>
> Of course this is a very summarized view of the two technologies. There
> is a lot more to both, but it is not clear to me that one or the other
> would better fitted for large hierarchical data.
>
> One thing I have noted is that Alfreso is in full buzz mode right now :)
> So it would be nice to have a real-world comparison of the two techs. It
> seems to me that Alfresco is more EDM oriented than Jackrabbit though in
> terms of a product.
>
> And last time I did performance comparisons, nothing could beat
> Jackrabbit in terms of indexing speed, and the possibility to use
> file-based persistence was a interesting choice for "lighter"
> configurations that still need speed.
>
> For me the big issue with Jackrabbit is to scale it to really large
> datasets. I'd love to be able to say that Jackrabbit can scale to a
> cluster of 10-20 machines in cluster and managed hierarchical data of 20
> million nodes amounting to 100TB of data :)
>
> Regards,
>   Serge...
>
> Jukka Zitting wrote:
> > Hi,
> >
> > On 10/9/06, Alexandru Popescu <th...@gmail.com>
> > wrote:
> >> Other than this, I guess it may be oke to have different solutions for
> >> this spec implementation (in case you are referring to this).
> >
> > +1 In fact I'd be very interested in seeing some comparisons on the
> > various aspects of the different JCR implementations. There's a lot to
> > be learned from different approaches to the same problem.
> >
> > BR,
> >
> > Jukka Zitting
> >
>
>


-- 
Best regards,

Christophe

Re: Alfresco + Jackrabbit

[Serge Huber <sh...@jahia.com>]

Well I looked at Alfresco a while back but for me the main difference 
was at the time :

- Nodes in Alfresco seem more file-oriented (basically it's mostly 
configured for that type of usage)
- Nodes in Jackrabbit are quite general

But the two implementations are quite similar, except that Jackrabbit 
has decoupled the persistence implementation in a way that makes it easy 
to choose a back-end fitting your deployment. On the other hand Alfresco 
is database oriented, which will help with some issues such as 
transaction management, clustering, etc.

Of course this is a very summarized view of the two technologies. There 
is a lot more to both, but it is not clear to me that one or the other 
would better fitted for large hierarchical data.

One thing I have noted is that Alfreso is in full buzz mode right now :) 
So it would be nice to have a real-world comparison of the two techs. It 
seems to me that Alfresco is more EDM oriented than Jackrabbit though in 
terms of a product.

And last time I did performance comparisons, nothing could beat 
Jackrabbit in terms of indexing speed, and the possibility to use 
file-based persistence was a interesting choice for "lighter" 
configurations that still need speed.

For me the big issue with Jackrabbit is to scale it to really large 
datasets. I'd love to be able to say that Jackrabbit can scale to a 
cluster of 10-20 machines in cluster and managed hierarchical data of 20 
million nodes amounting to 100TB of data :)

Regards,
  Serge...

Jukka Zitting wrote:
> Hi,
>
> On 10/9/06, Alexandru Popescu <th...@gmail.com> 
> wrote:
>> Other than this, I guess it may be oke to have different solutions for
>> this spec implementation (in case you are referring to this).
>
> +1 In fact I'd be very interested in seeing some comparisons on the
> various aspects of the different JCR implementations. There's a lot to
> be learned from different approaches to the same problem.
>
> BR,
>
> Jukka Zitting
>

Re: Alfresco + Jackrabbit

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 10/9/06, Alexandru Popescu <th...@gmail.com> wrote:
> Other than this, I guess it may be oke to have different solutions for
> this spec implementation (in case you are referring to this).

+1 In fact I'd be very interested in seeing some comparisons on the
various aspects of the different JCR implementations. There's a lot to
be learned from different approaches to the same problem.

BR,

Jukka Zitting

-- 
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Re: Alfresco + Jackrabbit

[Alexandru Popescu <th...@gmail.com>]

On 10/9/06, Frans Thamura <fl...@meruvian.com> wrote:
> anyone using Alfresco,
>
> i got an email from John Newton, said that Jackrabbit is just for flat
> file, and bad solution for hiearchical data, which alfresco focus on
>
> i see the structure of Alfresco is different

I don't know who John Newton is (mea culpa), but afaik Jackrabbit is a
valid and even more, afaik, the most complete JSR170 implementation.
Other than this, I guess it may be oke to have different solutions for
this spec implementation (in case you are referring to this).

./alex
--
.w( the_mindstorm )p.



>
> any input?
>
> Frans
>