Sometimes I think... Some of us are shortsighted and some of us are
longsighted...
Us longsighted folks focus on these other technologies, seeking a golden egg
that will solve many many problems at once. Challenge is that we miss the
obstacles that our in our immediate path to those solutions.
Us shortsighted look for quick upfront solutions, spending time wiring
immediate solutions that may replicate something we didn't realize already
existed. We may not see the longer term solutions and be putting up
obstacles to achieving those solutions.
I'm sure that somewhere in the middle of the two is a pragmatic approach
that addresses both risks.
Graham, the question was "how can I inject my own addon into an already
deployed dspace application?". I'm just pointing out that a number of big
projects already invested time into writing tools that support this sort of
thing. And we've seen them used within our own organization. I hope we do
not write our own solution without first dialoging with those in our own
organization who have already "experienced" more options than we are
currently considering.
Mark
On Thu, Sep 1, 2011 at 3:33 PM, Graham Triggs <grahamtri...@gmail.com>wrote:
> On 1 September 2011 22:20, Mark Diggory <mdigg...@atmire.com> wrote:
>
>> On Thu, Sep 1, 2011 at 2:11 PM, Mark H. Wood <mw...@iupui.edu> wrote:
>>
>>> > But, I agree with your point. It does seem like we can find ways to
>>> make
>>>
>> > this easier post-1.8.0. You should be able to Install DSpace and then
>>> > "drop in" some add-ons & configure them as needed.
>>> >
>>> > Technically, you can basically do the "jar drop-in" thing with custom
>>> > Curation Tasks or separately-released Curation Tasks (like Replication
>>> > Task Suite, https://jira.duraspace.org/browse/DS-876).
>>>
>>>
>> Well, we need a framework for doing this... Ironically, this is what OSGi
>> is, I don't think folks get that, we should be watching DuraCloud and
>> Sakai CLE (http://sakaiproject.org/sakai-cle) both are Felix based, both
>> provide a framework to inject "addons" into a running instance of the
>> application. I hope we do not reinvent the wheel simply because we can't
>> grok the acronym OSGi, even the Attlasian folks get this (
>> http://confluence.atlassian.com/display/DEVNET/Atlassian+Plugin+SDK+Documentation
>> )
>>
>>
> Yes, OSGi makes it possible to dynamically load and unload modules, to
> dynamically wire service points. It gives you a framework to formally
> specify what those service points are. It makes it possible to develop the
> kind of small footprint, dynamically delivered systems comprised of
> functionality / applications split into logical packages that the kind of
> environment that OSGi was created for depends on.
>
> It makes all of that possible. But only when you carefully design what
> those modules are. Only when you take care to understand and respect what
> the specification lays out your responsibilities to be. When you take care
> over where your modules interact, and how they communicate with each other.
>
> There is nothing 'magic' about OSGi - it's a registry/wiring of services,
> and gives each module it's own ClassLoader. If you don't take care of making
> sure you do things well, then whilst OSGi is capable of delivering good
> reliable systems, it's all too easy to end up with a system that may appear
> to work to a degree, but:
>
> a) may be bloated through multiple copies of the same code loaded in
> different modules/bundles
> b) may be bloated through multiple revisions of the same module/bundle
> being loaded in memory
> c) may have runtime failures through illegal access of objects across
> different ClassLoaders
>
> As I say, there is nothing about OSGi that prevents you from running into
> these issues. You need to understand the requirements, have a good design,
> and implement it correctly.
>
> I'm not saying that to be negative about OSGi, because really, it is what
> you make of it. But even without OSGi, there are enough specifications and
> technologies that we are working with right now, that we need to be able to
> understand properly, respect, and implement correctly. Because OSGi will not
> make us better at doing that, it will give us more ways to make our systems
> worse.
>
> G
>
--
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Esperantolaan 4 - Heverlee 3001 - Belgium
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
