>
> > 1) When and item is added, I wish to include bitstreams in the item in
> > particular bundles. These could be thumbnail images,
> > or bitstreams derived from processing of already available bitstreams.
> > For example, if I add spatial files to an item I wish to be able
> > to be able to add various spatial indexes to specific bundles, as well
> > as thumbnails.
>
> So can I infer that in this use-case, the latency imposed by batching
> these operations in media filter is intolerable/undesirable? (You could
> run it quite frequently if needed). I'm generally cautious about
> entangling the generation of derivatives and the addition of the primary
> artifact. You want the latter always to succeed, since the former can
> always be regenerated. There also can be issues of response-time to
> worry about, depending on the derivative(s). These are a few of the
> motivations behind the Media-Filter architecture, rather than having
> synchronous creation of derivatives, which seems to be your objective
> here.
In some cases it is intolerable as I wish to have these derivatives ASAP, in
other cases it can suffice. In fact my first code uses media filters.
> 2) When item, metadata or bitstreams are changed (modified or
> > removed), I wish to update various metadata fields to ensure that
> > they are consistent with the data held in the item.
>
> Consistency constraints form a very interesting class of use-cases.
> Are these changes coming though the admin UI, or elsewhere, or anywhere?
> Do you want a consistency check to be performed on any change, or only
> certain ones, etc?
This would be specific fields. For example, I maintain dc.coverage.*
metadata that I wish to generate from either a user interface or from data
in bitstreams.
> 3) When item, metadata or bitstream is added, I wish to update the
> > configuration of other co-operating applications to include the
> > changes made to the DSpace base data. For example, if I add a spatial
> > file to an item, then I want to add this item to a WMS
> > server so that it is also available to spatial clients.
>
>
> This is in the sweet-spot of the event mech - you could have a very
> simple consumer that does this notification following the creation
> events that stem from use-case 1.
Exactly. This case fits well.
If you need a tighter coupling than the media filter can provide,
> we have talked about providing an in-process asynchronous message queue
> consumer (we already have a prototype enterprise JMS queue, if you would
> want to look at that, but it might be over-kill). Let me know if you are
> interested in this alternative.
I'm interested.
> As to your current code, I can see how this will work, and it's fine
> in the interim, but I don't think in future releases we will want to
> expose bare DB connections (getDBConnection()), since this breaks
> some encapsulations we are striving for in our DAO and other work.
I expected this. So I'm still looking for a long term solution.
John
John
> > _______________________________________________ DSpace-tech mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>
>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
