that sounds ideal. I know myself and others are not entirely comfortable with jackrabbit - particularly the way it stores thing in RDBMS (although if we are using jboss cache and its persistence - I am not sure if we will do much better then blob storage??). On Thu, Nov 20, 2008 at 3:05 PM, Randall Hauch <rhauch(a)redhat.com&gt; wrote: > Actually, I'm hoping that we can support binary property values > (which is > actually where JCR stores file content, but you know that :-) in > memory > mapped (direct) buffers. That way, they don't take up any memory. > Plus, by > using federation and a file system connector, we could store these > large > files on the file system and just handle the "references" as property > values, opening a stream to the underlying only when required. Of > course, > you're app would have to pay the price for streaming gigabytes of > information. :-) > > How does this sound? > > Best regards, > > Randall > > On Nov 19, 2008, at 9:09 PM, Michael Neale wrote: > >> For our SOA repository, and rules - its possible we are looking at >> large single artifacts, as well as many small ones (which kind of >> stretch most JCR implementations). One idea floated is to (possibly) >> one day store entire machine images (OMG !!!) in the repository >> (obviously in memory will not work in that case !). But its hard to >> nail things down isn't it... >> >> On Thu, Nov 20, 2008 at 7:21 AM, Randall Hauch <rhauch(a)redhat.com&gt; >> wrote: >>> >>> Stefano, this sounds great! Personally, I really like to hear >>> these >>> kinds >>> of use cases and scenarios. It's always important to know >>> whether we're >>> working on the "right" set of features. So keep these use cases >>> coming! >>> >>> And, please feel free to suggest or discuss features that might be >>> useful, >>> too. For example, do you think JCR versioning will be an >>> important part >>> of >>> your approach, or will you implement your own approach to managing >>> history >>> by designing the hierarchy to handle it? Also, do you have an >>> idea about >>> how much information the repository will store (perhaps broken >>> down by % >>> in >>> uploaded files, and about how big those files will each be). >>> >>> Best regards, >>> >>> Randall >>> >>> On Nov 18, 2008, at 3:34 PM, Stefano Maestri wrote: >>> >>>> Hi all, >>>> as said in a previous post I'm going to start a SOA/Enterprise >>>> project >>>> using DNA for an important part of the project. >>>> I'm finishing the design of the whole application, but I can >>>> describe >>>> here the main idea and how DNA will be related. >>>> >>>> In a nutshell we are SOAfing a complex system of a customer >>>> (J2EE+.NET+Oracle mainly, with external partner and provider >>>> with SOAP >>>> service and/or custom legacy services). >>>> The system use a lot of data stored in various resources (mainly >>>> relationl DB, but also someone provided from partner services). >>>> Some >>>> code (in all languages) apply business rules to this data and >>>> transform >>>> it in a some enrich information (information=data+Business rules). >>>> Aggregating this data we build a final report to client that is >>>> the >>>> final product. >>>> As said we are moving to SOA and we are identifying services and >>>> aggregation of them. The area where DNA could be very useful is >>>> solving >>>> the problem of keeping track of information during time. >>>> IOW we are asked to be able to provide not only current >>>> information, but >>>> also information related to a particular moment (remember >>>> information >>>> for us= data + business rules). >>>> The system (or better a lot of service provider we are >>>> considering part >>>> of the system) haven't ability to keep data or bsiness rules >>>> history, so >>>> we have to store in some other places answer to be able to >>>> retrive them >>>> in future. >>>> Here DNA could help us: the basic idea is to use JBossESB as >>>> integration >>>> layer where a MessageStore could store messages into DNA where >>>> we can >>>> apply different sequencers to extract information and organize >>>> it for >>>> our different future purpose. >>>> >>>> ok, a bit confused, but it's late night and I'm tired and >>>> moreover the >>>> project is on its start up. >>>> >>>> I'll try to explain better details regarding DNA very soon, as >>>> soon as I >>>> finished my design. >>>> >>>> bye >>>> S. >>>> _______________________________________________ >>>> dna-dev mailing list >>>> dna-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/dna-dev >>> >>> _______________________________________________ >>> dna-dev mailing list >>> dna-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/dna-dev >>> >> >> >> >> -- >> Michael D Neale >> home: www.michaelneale.net >> blog: michaelneale.blogspot.com > > -- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com

And, please feel free to suggest or discuss features that might be useful, too.

For example, do you think JCR versioning will be an important part of your approach, or will you implement your own approach to managing history by designing the hierarchy to handle it?

Also, do you have an idea about how much information the repository will store (perhaps broken down by % in uploaded files, and about how big those files will each be).