First off, Erik, thank you for taking an interest in any way. As I've said before, I'm not trying to represent myelf as a Lucene expert, so having someone point out flaws is goooooooood.
On Wed, 19 Jan 2005, Erik Hatcher wrote: > >> Could you elaborate on some use cases? > > > > Sure, and I'll pick the one that's been driving me along: > > > > I have a set of J2EE servers, all of which can generate new content for > > search, and all of which will be performing searches. They're on > > separate > > machines. Sharing directories isn't my idea of "doing J2EE correctly." > > "doing J2EE correctly" is a funny phrase. If sharing directories > works and gets the job done right, on time, under budget, can be > adjusted later if needed, and has been reasonably well tested, then > you've done it "right". And since its in Java and not on a cell phone, > its basically "J2EE". Absolutely. I'm not trying to make fun of pragmatic, working solutions. Nor am I sneering at those who've done it by sharing filesystems or whatever. > Also, what about using Lucene over RMI using the RemoteSearchable > facility built-in? Well, I'd prefer to avoid RMI. App servers typically have far better transport layers than raw RMI, internally, and JCA can leverage that. > > Therefore, I chose to represent Lucene as an enterprise service, one > > communicated to via a remote service instead, so that every module can > > communicate with Lucene without realising the communication layer... > > for > > the most part. > > And this is where I think the abstraction leaks. > > The Nutch project has a very scalable "enterprise" approach to this > type of remote service also. *nod* I'll look it up. > > Plus, I no longer violate my purist's sensibilities. > > Ah, now we get to the real rationale! :) > > I'm not giving you, personally, a hard time, really ... but rather this > purist approach, where "purist" means fitting into the acronyms under > the J2EE umbrella. I've been there myself, read the specs, and cringed > when I saw file system access from a session bean, and so on. Well, in all honesty, there IS a small factor of "Gee, I can use an acronym here!" involved. It's not ALL that's involved, of course - I think the connector's transparency might be a real benefit for others as well as satisfying my own "I need a deployed component, and not a service I have to tune" need. > > The Hits object could CERTAINLY use optimization - callbacks into the > > connector would probably be acceptable, for example. > > Gotcha. Yes, callbacks would be the right approach with this type of > abstraction. Just as a general question... is it efficient to retrieve a Document by, uh, a sort of Lucene key? (Is there such a thing?) If there is, I can code up a callback procedure in almost no time. (There are some other issues to address first, but THAT would be easy to do.) > >> JCA sounds like an unnecessary abstraction around Lucene - though I'm > >> open to be convinced otherwise. > > > > I'm more than happy to talk about it. If I can fulfill my needs with no > > code, hey, that's great! > > Would RemoteSearchable get you closer to no code? Dunno, I'll investigate. > > I just haven't been able to successfully do so > > yet, and everyone to whom I've spoken who says that they HAVE > > managed... > > well, they've almost invariably done so by lowering the bar a great > > deal > > in order to accept what Lucene requires. > > I'm definitely a skeptic when it comes to generic layers on top of > Lucene, though there is definitely a yearning for easier management of > the lower-level details. On my part, too. If I coul get a Directory reliably and quickly using an RDMS, I'd have gone that route. > I'll definitely follow your work with LuceneRAR closely and will do > what I can to help out in this forum. So take my feedback as > constructive criticism, but keep up the good work! Again, no problem - and thank you. The things you bring up are issues I might not be aware of, so it's good to see them and evaluate them. ----------------------------------------------------------------------- Joseph B. Ottinger http://enigmastation.com IT Consultant [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
