On Thu, Mar 6, 2008 at 9:20 AM, Reuben Pasquini <[EMAIL PROTECTED]> wrote:
> We're evaluating several packages > for setting up an institutional repository. > I'm very impressed with D-Space, but have > a few questions - hope the list can help me out. I'll answer what I can, but I'll have to defer to greater expertise on some of these! > *. It looks like manakin actually runs D-space > code internally at its core, but does > the web interface using Coccoon. > I originally thought that Manakin accessed > D-Space as a client via EJB or SOAP or whatever: > [Web Browser] > <-> [Manakin server] > <-> [D-Space server] > , but that is not the case, right ? Right. > *. Is it safe to have a Manakin instance and a D-Space instance > running on the same box, and pointing at the same > /dspace work folder, or is it possible for data to be corrupted > if the two servers attempt to modify the same object at the > same time ? There shouldn't be anything wrong with this; it's how they're designed to work as far as I can tell. > *. Is it safe to setup the /dspace work-folder on a network-mounted > drive ? I can't see why not. Anybody else? > *. Is it safe to have 2 or more DSpace/Manakin instances running > on separate servers pointing at the same /dspace network-mounted > folder, as long as each server has its own copy of dspace/config ? No idea, but this sounds a little dangerous to me. Where I am, we keep our test instances and our production instance completely separate from each other -- different DB, different assetstore, different folders, different vhost altogether. > *. If it's not safe to have multiple servers sharing a read+write > /dspace folder, > then would it be safe to have multiple READ-ONLY > (anonymous asset-browsing) instances of DSpace/Manakin sharing a > read-only network-mounted > /dspace folder if we only allow a single DSpace instance to > perform > updates ? This sounds almost feasible, but I'd think you'd have to hack a lot of code. (Or maybe not -- maybe it'd be as simple as not letting Manakin show any of the admin functions on the read-only instances.) Why were you wanting to do this? Maybe there's another way to get what you're after. > *. For branding or customizing the web interface - it looks like we > have a choice of either: > > o. working with the D-Space .jsp pages - which are pretty > old-school with a lot of embedded java > o. jumping into XML/XSL world with Manakin > > Is that right ? Yes. > *. Is there any plan afoot to try to update the D-Space .jsp pages > by pushing some of the java-code into the dspace: tag-library, > and pushing the form-processing out to JSF or struts, > so we can point a web developer/designer specialist > who likes to work with > XHTML+javascript+CSS2 at the pages, and just let him do his thing > with DreamWeaver or whatever ? Not that I know of. The development path as I understand it is moving away from JSP altogether, in the direction of Manakin. I don't know how I'd throw a Dreamweaver dev at Manakin; I suppose I might throw a webcrawler at my Manakin instance and pass over the resulting HTML/CSS to them, but I'm almost certain that would end up giving my Manakin dev frothing-at-the-mouth fits. Anybody got any better ideas? Dorothea -- Dorothea Salo [EMAIL PROTECTED] Digital Repository Librarian AIM: mindsatuw University of Wisconsin Rm 218, Memorial Library (608) 262-5493 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
