Hi Richard, A few responses inline...
On 8/1/2011 10:44 AM, Richard Rodgers wrote: > Hi all: > > I have a few remarks inline, but my bottom line: I think this whole area > needs more analysis before leaping into any solution, esp. right before a > release. > The Domain Model work is interesting and creative, but I'm not convinced we > understand our use-cases well enough yet to judge it's applicability. > > Richard > On Jul 29, 2011, at 5:53 PM, Tim Donohue wrote: > >> Hi All, >> >> I have a few more background details to add to Mark's description, >> followed by a few comments of my own. >> >> == A little more about the problems we are encountering == >> >> As Mark mentions, for 1.8.0, Richard R& I would like to release >> 'dspace-replicate'. More info at: >> https://jira.duraspace.org/browse/DS-876 >> >> Unfortunately, the reality here is that 'dspace-replicate' sits in SVN >> Modules (svn/repo/modules) and also depends on 'dspace-api'. So, to >> release 'dspace-replicate', we would need to *first* release >> 'dspace-api'. But, at the same time, 'dspace-api' can only be released >> if we perform the full packaged DSpace release from Trunk. >> >> What results is a chicken-or-egg issue, where 'dspace-replicate' cannot >> be included in the full packaged DSpace release unless it's released >> *first*, but it cannot be released first as it depends on dspace-api. > > I guess I don't really understand this point - I see no reason why the > dependency here is of special concern, or why there is a problematic > chicken-and-egg situation. > You say "include replicate in full packaged release", but I see no > requirement for this at all. Replicate is a good example of > of a candidate for 'asynchronous' release, which means precisely *not* at the > same time as the packaged release. Why is it a good idea to require that all > add-ons be synchronized? > I'm imagining this is the sort of thing (cloud replication) that one would > not immediately decide on, but could elect to add to one's system later. True, you are correct. A third option is the asynchronously release the 'dspace-replicate' code entirely separate from DSpace 1.8.0. There may be some advantages to that. But, I also see several distinct disadvantages: 1. We need separate installation & upgrade docs (and general documentation) for 'dspace-replicate'. Where do those docs sit? Do they go in with 1.8.0's official docs, or are they totally separate? This module would *not* be a part of 1.8.0 out-of-the-box, but is just "compatible with 1.8.0". 2. We need to make it clear how to install 'dspace-replicate' both to command-line (copy JARs to [dspace]/lib/) and also how to install it to XMLUI (copy JARs to [dspace]/webapps/xmlui/WEB-INF/lib/) and JSPUI, etc. (And also make it clear that all these installs are separate -- you cannot simply pull the JARs into a single location & expect it to be fully installed throughout all of DSpace.) Is this "user friendly" enough for a tool that is meant to make things more "user friendly" by bringing more backup & restore functionality to Admin UI? Or are we accidentally adding an unnecessary barrier here (by not having an easy-to-install option, or having it already bundled out-of-the-box)? Obviously, both of the above issues can be resolved (to some extent) with better documentation. They could also be resolved better in the future by perhaps creating a "module installer" which can auto-install the JARs for you to all the proper locations. Also, remember, 'dspace-replicate' is *not* just for cloud-based replication. It could also be used to perform on-demand, day-to-day backups (to a local mounted drive, etc.), by making the AIP Backup & Restore tools available to the Admin UI. So, I'd argue that 'dspace-replicate' is useful to *anyone* who wants to be able to kick off backups or restores from the Admin UI (and not just those wanting to do so via cloud storage). In other words, if 'dspace-replicate' could be generally useful to most DSpace system & repository administrators, do we really want to force everyone to do a separate installation process in order to utilize it? >> >> So, the options for moving forward currently include: > So I see a third option: do nothing (for the moment). I had no problem > compiling the replicate code from the pom (including it's dependency on > dspace-api, and 3rd party libraries), and deploying the jar artifacts, > and configuration files to a DSpace installation. So I think we should be > clear that not doing option 1 or 2 below will not *prevent* the use of the > replication module. Of course, we could add scripting or other tooling to > make it easier, but it is not a complicated process as is. "Do Nothing" is a third option. But, I'd argue it's not very beneficial for 'dspace-replicate' module (for the reasons described above). I honestly feel that 'dspace-replicate' could be a major feature of 1.8.0, if we wanted it to be. Again, it's not all about "cloud storage" -- it does enable cloud storage, but it's also useful to normal hard-disk backups. As you can already probably tell, I feel rather strongly that 'dspace-replicate' should be pre-installed in 1.8.0. (If we had an "easy installer" for modules, I'd be willing to go that route. But, I'm not a fan of the manual installation route of "copy these configs here, now copy these JARS to these 2-3 places, then restart Tomcat -- if you did this all correct, then you'll see it appear. Otherwise, you did something wrong or copied the JARs to the wrong directory.") I would be interested to hear what others think here though. If I'm the only one who thinks 'dspace-replicate' would make a nice out-of-the-box feature, then I'm fine with being overruled. This is a democracy after all :) - Tim ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
