Reuben, See my answers below:
On Mar 6, 2008, at 9:20 AM, Reuben Pasquini wrote: > Hello! > > 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. > > *. 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 ? Correct. > > *. 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 ? > It is safe, and we do it on a regular basis here. Typically before we release a new version into production we run both the current and new version along side each other for a period of time. This allows users to see the new version on live data before we finally make the switch. However there is a caching problem that prevents dspace from being run in a load-balanced environment. The back-end api at several points caches data and has no mechanism for refreshing its cache. So if you add a new community on one instance it will not show up in the other instance until the the JVM has been restarted. > *. Is it safe to setup the /dspace work-folder on a network-mounted > drive ? Yes. Our production /dspace folder is on a network-mounted drive. > > > *. 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 ? Yes. However you will need to make sure that your network-mounting technology does not require exclusive locks on files. See caching note, on running two servers. > > *. 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 ? > > *. 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 ? Correct. > *. 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 am aware of. > > Thanks for the help! > Reuben > > > ------------------------------------------------------------------------- > 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 > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------- 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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
