It would be good to see more documentation of the project in the wiki. We may be able to provide more transparency and peer review on the project if there were more detail concerning it. So far the CGI work has about one paragraph of description. And we all appear to want to contribute viewpoints in this area, it would be better to bring the whole topic and the code work into center stage with greater detail on what your up to.
https://wiki.duraspace.org/display/DSPACE/CGIProposal I'm of the opinion that more coordination needs to occur here to make sure we are all not on a collision course with our work. We've already had to readjust Reviewer workflow once to adapt to Curation tools and we will need a significant dialog with you concerning the fact that curation tools have a bit of incompatibility with how it is wired to hardcoded workflow stages where the configurable Reviewer workflow is, well an non-hardcoded series of configured workflow stages. If you have time next week, it would be great to have a skype call or IRC chat on the topic. TBH, I really don't think that architectural redesigns of critical areas of DSpace should happen without significant discussion and feedback with the community. This includes what we are about to present with the Reviewer Workflow. I think its important to bring this stuff into the community earlier to asure that when others want to participate (GSoC or otherwise) theres a sufficient door open to allow that participation. It would also allow for less replication of effort because we are already working similar activities with Reviewer Workflow which will be coming out shortly as well. So, yes, I would love a look, but also, I think we want the community to have an opportunity for peer review and possible opportunities for GSoC students to participate in the work. Best, Mark On Thu, Apr 7, 2011 at 10:32 AM, Richard Rodgers <rrodg...@mit.edu> wrote: > HI Mark: > > You might want to keep an eye on the CGI stuff we are working on - it > essentially amounts to your option #3 > (DB serialization). I should have a demo ready by OR11, but if you are > interested in 'early access', I'd be happy to give you a look. > > Thanks, > > Richard > On Apr 7, 2011, at 11:43 AM, Mark H. Wood wrote: > >> On Wed, Apr 06, 2011 at 11:27:53AM -0700, Mark Diggory wrote: >>> On Wed, Apr 6, 2011 at 6:10 AM, Mark H. Wood <mw...@iupui.edu> wrote: >>>> On Tue, Apr 05, 2011 at 09:46:26AM -0700, Mark Diggory wrote: >>>>> Recommendations are that a web ui (and specifically the XMLUI is of >>>>> interest in this case) be constructed not on the "Xml files" >>>>> themselves, but utilizing the DSpace Configuration Service. >>>> >>>> So is the Configuration Service able to represent *structured* values >>>> in an effective and comprehensible fashion, as opposed to the horrid >>>> mess that we sometimes get when trying to cram them into Properties >>>> format using the old ConfigurationManager? >>> >>> No, it doesn't at the moment. But switching over to XML is even more >>> of a nightmare, ATM. It will just introduce more "custom parsing" >>> approaches like we have in various classes now. the goal of the 2.0 >>> work and the use of the service manager was an attempt to consolidate >>> "custom" parsing. >> >> Well that's what made me think of JAXB, since it writes the parsers >> for us and we just ask the resulting objects what was in the parse >> tree. I don't want to think about what "input-forms.properties" would >> look like, or the code it would take to decipher that. >> >>>> If not, and there's a need to serialize the resulting in-memory >>>> structures without a lot of fuss, we might want to look at (say) JAXB >>>> in cases where we need to express some kinds of complex relationships. >>> >>> Your heading in the right direction with the wrong technology. Spring >>> is JAXB in reverse, rather than binding custom XML to Java objects, we >>> use a standardized XML (or Java annotations) to wire together a series >>> of existing Java Beans. Because of this, there is no "binding" that >>> needs to be maintained, Spring already manages that, this is what I >>> was doing the best I could to reflect in my tutorial example here: >> >> I would certainly rather use Spring, which we already have to deal >> with, than introduce Yet Another Technology. But I don't recall >> seeing a way to get Spring to serialize altered "injectables" back to >> something it can read next time, and that seems to be a requirement? >> Something like JAXB is read/write. >> >> If we are going to have a web UI to alter forms and ingestion flow, we >> need to be able to store the alterations. (IOW we *do* need a >> binding.) We can do that several ways: >> >> 1. write the altered definitions out in the same XML format we use >> now. It was designed to represent the relationships in question, >> and XML does so naturally. >> >> 2. write the altered definitions out in Properties format so that >> ConfigurationManager or ConfigurationService can deal with them. >> This forces us to represent structure in a fragile and unnatural >> manner. >> >> 3. translate the XML schema to a database schema and hide all the >> relational hair in DBMS tables. The DBMS is supremely adapted to >> supporting us in this, once we get the entities clear and the >> relationships represented in code. >> >> 4. adjust our set of classes as needed so that we can use a >> serialization toolkit like JAXB to take care of the storage details >> for us. >> >> 5. write out a new Spring context (more XML). See below for why this >> is really really hard. >> >> There may be others. If those are the choices, I'd probably go with >> #3, even though it may be the most work up front. >> >> The DBMS approach still requires a loader for the default setup. I'd >> still go with XML for this. >> >>> https://wiki.duraspace.org/display/DSPACE/The+TAO+of+DSpace+Services >>> >>> In this can there is no longer a need to worry about mapping/parsing >>> XML to bind a the Launcher commands to, its just spring and done at >>> runtime config by the service manager. We want the same application >>> at all the levels of the configuration... major portions of what are >>> in dspace/config would/should be redressed as spring configuration. >> >> Yes. But what does that have to do with the Configuration Service? >> The example isn't using that anywhere I can see. Rather it introduces >> a new Service which is configured through Spring. >> >>> Likewise, we should consider ( and this is a direct concept from the >>> original DSpace 2.0 SimpleStorageService work) that we will want to >>> associate configuration with the Domain Model Entities, and that its >>> the structural framework we seek to align with. If you look >>> throughout the configuration what you see are three types of >>> abstraction >>> >>> a.) properties of a plugin >>> b.) wiring of plugins into a service >>> c.) associating a service/plugin with a DSpace entity (Community, >>> Collection, Item) >> >> d.) standalone properties, used all over DSpace >> e.) lists of standalone properties >> f.) standalone hierarchial structures masquerading as sets of maps with >> funny-looking keys >> >>> for (a) and (b) the Spring based Service Manager with associated >>> Configuration Service is sufficient. The takes the need to configure >>> DI in the dspace.cfg altogether because you do it in a more flexible >>> "spring" approach. Thats a considerable amount of hierarchy >>> eliminated or place under the management of Spring. >> >> One may wonder why we need the Service Manager for this. It would >> seem that Spring suffices. >> >>> for (c) we should work on the Domain Model such that we can attach >>> properties as attributes of DSpaceObjects and thus if you review >>> configurable submission, configurable reviewer workflow, curation >>> tools, discovery configuration, etc you will find components in each >>> that should be properties attached to the DSpace Domain Model >>> Entities. >> >> Sensible. >> >> d, e, f need to be assigned to beans, and then Spring can just jack >> them into the appropriate objects. dspace.cfg, this.cfg, that.cfg, >> quux.cfg *all* go away and we don't need a ConfigurationAnything. >> >>> We will ultimately end up with the question being, what from our >>> current legacy configuration is attached to the Domain Model via db >>> configuration and what gets sent to Spring configuration as wiring of >>> the application. >> >> At that point, external configuration boils down to "dude, where's my >> database?" One question whose answer *does* fit the Properties format >> (for standalone applications) and can also be supplied by a servlet >> container via JNDI. Or let Spring handle the standalone case. >> >>> As a strong example, I would take the InputForms and consider that >>> there are two components, (1) validation/schema that should be >>> associated with the Item being created and (2) a set of form fields >>> that are more associated with a "view" in the user interface. >>> >>> However, we really start to rethink what is"Domain Model" and "What is >>> Service" when we dig into the Submission and Reviewer Workflows, >>> here, depending on direction, we end up with two completely different >>> treatments, just taking CS we have: >>> >>> (1) the assignment of a submission workflow to a collection. >>> (2) the assignment of steps to a workflow id >>> (3) the configuration of the capabilities of a step (inputforms and >>> dspace.cfg) >>> >>> >>> Treatment A : Make it a legitimate Domain Model >>> >>> We can treat the whole as Domain Model (which is appropriate given >>> submission is at the heart of DSpace). If we do so, we end up with: >>> >>> (2) is a new Domain Model where, for the legacy case, we actually >>> crete new database tables and DAO bindings for the Submission Workflow >>> Steps. >>> (1) is a Domain Model Association of workflow2collection >>> (3) are simple configuration properites attached to the Collection >>> and/or workflow and step entities. >>> >>> Treatment B : Make it all Service Manager / Spring based. >>> >>> (2) is treated as a set of steps wired in spring configuration >>> (1) are simple properties on the Collection entities associating the >>> workflow with the collection >>> (3) are simple properties on the Collection and/or workflow and step >>> entities. (requires more hierarchical config) >>> >>> This is a simpler design then Treatment A to get into place, but still >>> puts configuration of workflow in the developer hands. Ultimately >>> Treatment A takes a little more thought and work, but the payoff to >>> the community is much more significant and it ultimately is the right >>> choice. >> >> Well, if we want to provide UI to customize this stuff, then B really >> can't be done. Because, to persist the changes, we have to figure out >> where Spring got its instructions for wiring up the objects, and >> replace those instructions through a big pile of code that knows how >> to write Spring context descriptions. The "figure out where Spring >> got it" is the part I don't see how we can do. Depending on how >> things are mixed together, we may not be able to do the "replace with >> new wiring" either since we might stomp all over things that have >> nothing to do with what we are altering. Unless you want to pull it >> all into (one or more!) DOM trees, do surgery thereon, and serialize >> it all back to the appropriate place(s) (which we don't know). >> >> So we really first need to work out what we want to configure using a >> text editor, and what using DSpace UIs. >> >>> Theres a great deal of opportunity here if we get the design right >>> from the get-go. What I am really trying to emphasize to the group is >>> that you need to think out the overall DSpace design goals and >>> strategy rather than focusing in on hacking little areas of the >>> codebase, we should avoid custom parsing, likewise we should recognize >>> that we have historically taken on a strategy for solving >>> customizations to DSpace that is pigeonholing our application design, >>> and that this approach selects for not creating or altering the true >>> Domain Model for DSpace in favor of individual, unique and messy on >>> the spot solutions that meet a local need. The later are like a >>> cancer on an originally clean DSpace design. I really think the core >>> committer groups responsibility to achieve a consensus on approaches >>> that should/will be allowed to be contributed to DSpace and thus >>> mediate the danger of these narrow vision micro-solutions continuing >>> to propagate. >> >> I agree that it is time for an overall review of configuration with an >> eye to supplying *representations* and mechanisms that are appropriate >> to the code, the entity (Collection, Community, Site) managers, and >> the system administrator. (If I'm not putting words in your mouth.) >> It seems clear to me that DSpace provides configuration facilities >> which no longer match the ways it needs to be configured and the ways >> that the people responsible for its functioning want to interact with >> it. >> >> -- >> Mark H. Wood, Lead System Programmer mw...@iupui.edu >> Asking whether markets are efficient is like asking whether people are smart. >> <ATT00001><ATT00002..c><ATT00003..c> > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > -- Mark R. Diggory @mire - www.atmire.com 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Technologielaan 9 - 3001 Heverlee - Belgium ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
