Hi Scott, Thanks for the thoughts. Yes, keeping backward compatibility can be a major chore, and will steal cycles from the more forward-looking stuff if you're not careful. I am generally ok with throwing some of the major interfaces/classes out as will no doubt be done as the Springification progresses -- it will be a happy day when we can finally get rid of the Server and Module classes for good.
The old llstore interface is a bit tougher to let go of, since it's one area where I know of several third-parties who have written plugins against it. However, the active projects I know of (Honeycomb 2, iRODs, DuraCloud) have been working on plugins to work at the Akubra level, so the change won't adversely affect them at all. - Chris > Hi, Chris -- > > I was just talking to one of my coworkers about the issue of Fedora and > backwards-compatibility with older versions, and then I opened my email and > read your post. > > In general, I'd say that as Fedora moves forward, and the old architecture > gets replaced with newer, more streamlined pieces, this problem is only > going to get worse, not better. At some point I think we need to bite the > bullet and accept that certain legacy APIs will no longer be supported in > future versions. The sooner that decision is taken, the easier it will be > in the long run, I believe, as developers will not need to spend so much > time making sure their new functions work with older code, and plugin > maintainers will not need to refactor so much of their code to conform to > new APIs when they do get around to making the switch. I personally would > much prefer you spent your time working on the new Spring framework, and as > a module developer out in the world, I'd be willing to rewrite my pluggable > modules to work with the new system so that the Fedora committers can devote > their energies to bug fixes and new features. > > I haven't looked at the roadmap in a while, so I don't know what the targets > are for Fedora 4. But a major release seems like a good place to cut bait. > > -- Scott > > Steve Bayliss wrote: >> >> Hi Chris >> >> It sounds like there's probably not a clean way (at least without a >> substantial amount of work) to resolve this, and that ultimately >> third-party >> plugins will need to be updated to be compatible with this and future >> releases. An inevitable consequence of the package renaming that we >> perhaps >> didn't foresee at this level of detail at the time. >> >> So long as we make it clear in the release notes that this is the case >> people will be aware and can do the necessary work to update their plugins >> for this (and future releases). >> >> Steve >> >>> -----Original Message----- >>> From: Chris Wilper [mailto:[email protected]] Sent: 16 August 2010 >>> 08:00 >>> To: fcrepo-dev >>> Subject: [fcrepo-dev] Legacy llstore plugin difficulty >>> >>> >>> Hi all, >>> >>> One of my tasks for the 3.4 release, which I'd hoped to complete last >>> week, was a "legacy llstore adapter". Since package names have >>> changed since 3.3 (from fedora.server to org.fcrepo.server), and the >>> LLStore interface itself has changed a bit, the goal of this work was >>> to allow legacy plugins written against the old interface >>> (non-Akubra-based) to work with 3.4 without requiring code changes to >>> them. >>> >>> It didn't work out so well :( >>> >>> My goal was to put together an adapter module that spoke the new >>> interface, but wrapped instances conforming to the old interface. >>> Originally I thought I could just use the 3.3 jars that included the >>> old lowlevel package classes. I started going down this road last >>> week, and quickly discovered that in order for the adapter to work, it >>> would have to depend on a lot more than the legacy lowlevel classes. >>> But I held out hope, thinking I could put together a huge jar with all >>> the dependent classes and libraries. This turned out more challenging >>> than I expected; I still felt it was doable...just ugly. >>> >>> But that wasn't the big problem. No, the main problem I ran into, and >>> something that looks insurmountable at this stage, is the old modules' >>> dependency on a working Server instance to be provided to their >>> constructors. In order to give them what they expect without >>> requiring their code to change, I'd have to provide a >>> fedora.server.Server instance that wraps the org.fcrepo.server.Server >>> instance that is available. Worse, they may actually want to use that >>> Server instance...and call getModule("old-module-interface-name"). I >>> can't see a way around that maze of twisty passages... >>> >>> Unfortunately, this means old versions of third-party llstore plugins >>> that are not Akubra-based aren't going to work with this release. >>> Right now, trunk has two options: >>> >>> akubra-fs (the default option, this is the akubra impl that goes >>> against a plain old filesystem) >>> legacy-fs (the legacy, default filesystem-based llstore >>> implementation, non-Akubra-based) >>> >>> Thoughts/ideas? >>> >>> Thanks, >>> Chris >>> >>> -------------------------------------------------------------- >>> ---------------- >>> This SF.net email is sponsored by >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge >>> http://p.sf.net/sfu/RIM-dev2dev >>> _______________________________________________ >>> Fedora-commons-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >>> >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Fedora-commons-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > > > -- > Scott Prater > Library, Instructional, and Research Applications (LIRA) > Division of Information Technology (DoIT) > University of Wisconsin - Madison > [email protected] > ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
