Return-Path: Delivered-To: apmail-incubator-jackrabbit-dev-archive@www.apache.org Received: (qmail 27905 invoked from network); 12 Jul 2005 15:28:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Jul 2005 15:28:43 -0000 Received: (qmail 84768 invoked by uid 500); 12 Jul 2005 15:28:41 -0000 Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jackrabbit-dev@incubator.apache.org Delivered-To: mailing list jackrabbit-dev@incubator.apache.org Received: (qmail 84754 invoked by uid 99); 12 Jul 2005 15:28:41 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jul 2005 08:28:40 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [212.249.34.130] (HELO picanmix.dev.day.com) (212.249.34.130) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Jul 2005 08:28:38 -0700 Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id j6CFSaT13169 for ; Tue, 12 Jul 2005 17:28:36 +0200 (MEST) Received: from [10.0.0.74] ([10.0.0.74]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2005071217283543:8370 ; Tue, 12 Jul 2005 17:28:35 +0200 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <42D3D57E.3090906@redshift.ch> References: <42D3D57E.3090906@redshift.ch> Message-Id: <0cc65dc1d3719903db66dd73ccb96af1@gbiv.com> From: "Roy T. Fielding" Subject: Re: considering use of jackrabbit Date: Tue, 12 Jul 2005 08:28:41 -0700 To: jackrabbit-dev@incubator.apache.org X-Mailer: Apple Mail (2.622) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 07/12/2005 05:28:35 PM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 07/12/2005 05:28:36 PM, Serialize complete at 07/12/2005 05:28:36 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Jul 12, 2005, at 7:36 AM, Franco Krattiger wrote: > we're considering using Jackrabbit for a medium scale web-application > that we are currently in the planning stage for. That's nice. > having perused the open issues on Jira i'm somewhat unsure whether > it's a wise decision to make use of the product prior to the first > official release. I think you should try using it. If you find problems, report them, preferably with the fix. That's what we do at Apache. Eventually, the problems (if any) will be very hard to find, but we can only get there one volunteer at a time. > the majority of the severe issues seem to pertain to the versioning > code. as versioning support is not a requirement for our application, > i could live with that limitation. That's good -- we wouldn't want you to keel over and die on us. > JCR-160 (query index not in sync with workspace) worries me, however. > searching is, not surprisingly, a key requirement for our app... if > the indexes run awry that's a bad thing :( Yep, we think so too. > so basically, i have the following questions: > > - generally speaking, can Jackrabbit in its current state be considered > for production use? We have not released it yet. We won't release it until we think it is ready to be released. > considering the open issues, this obviously would require workarounds > or an outright avoidance of certain functionality. i guess i'd like > to know if you guys are reasonably confident that the codebase > doesn't > harbor any more severe bugs beyond those already known and reported. That's a silly question. Do you require that of your own source code? > - for those familiar with JCR-160: just how quickly do the indexes > drift > out of synch? in my app, jackrabbit will probably see less than 100 > mutations/day... if the indexing creeps up rather slowly, it might be > feasible to work around it by reindexing on a nightly basis until a > fix comes along... I highly recommend testing it in practice, before deployment, with your own set of use-cases. Please report any findings back to the project and, eventually, we will all collaborate on making it better. However, if what you want is business assurances or OEM-style products, then you should seek out a business that will give you such assurances (my employer is one, but this is not intended as an advert in any way). Open source projects are about collaboration, not about giving vendors free support. ....Roy