On Sep 10, 2008, at 10:43 AM, Dorothea Salo wrote: > On Wed, Sep 10, 2008 at 12:36 PM, Mark Diggory <[EMAIL PROTECTED]> > wrote: >> The inclusion of new formats would have probably been best served as >> part of the SQL upgrade in >> >> http://dspace.svn.sf.net/svnroot/dspace/branches/dspace-1_5_x/dspace/ >> etc/database_schema_14-15.sql >> >> Then it would have been part of the update process. This XML file >> format thing is a bit overly complex when what really just needs to >> happen is that an SQL table is properly updated. > > Good point. Would I be right in hazarding a guess that this was > originally designed as a gesture toward relatively simple updating of > this set of configuration options (without direct database-mucking)? > And that this is therefore a special case of the general issues with > how difficult DSpace (and its underlying tech stack) is to configure? > > Dorothea
Unfortunately, its usually the case that attempts to create what would be simpler configuration capability usually ends up creating more complexity in maintenance in the long run. What really tends to happen is that you've just offset one open popular file format/update strategy (that there is actually a population of people working on and documentation for) with one that only you an a couple other folks in a very small niche comprehend. Thus introducing the increased cost of having to maintain, document and improve something that was originally (and erroneously) conceptualized to reduce costs. This sort of development actually hurts DSpace in the long run by increasing our maintenance burden when a better solution would have been to teach your users a little SQL or seek out and adopt some commonly accepted tooling/library. This is how I will always push back when it comes to customizations/ tooling that introduce local file formats and services that obscure and limit the underlying implementation. It is always better for your installation base to become better versed at existing popular technologies rather than force them into some local and constrained solution, even if it is supposedly "simpler". It is this kind of development that an open, peer reviewing community of developers elected by meritocracy will assist in limiting the occurrence of. This is why we need more people in the group referring to themselves as "developers" and not "users". New fresh blood in the commiter group and/or the walls torn down by a better SVN hosting solution with more granular permissions control. (But alas, I drift off subject). -Mark ~~~~~~~~~~~~~ Mark R. Diggory - DSpace Developer and Systems Manager MIT Libraries, Systems and Technology Services Massachusetts Institute of Technology Home Page: http://purl.org/net/mdiggory/homepage ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
