OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis4dam message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Meeting on May 19, 2015


Thx Ken & Irina for your feedback.

Thoughts below:

> Am 11.06.2015 um 06:31 schrieb kenb <kenb@ccs.neu.edu>:
> 
> Thanks for your offer.  This is a good start to the discussion about notification mechanisms.  I have a few thoughts about these mechanisms below.
> 
> On Fri, 22 May 2015, Sascha Homeier wrote:
> 
>> Hi Ken & other TC members,
>> at the last meeting you asked for volunteers to evaluate the asynchronous notification mechanism.
>> I think this is something I’d like to do when we come to this part (as we discussed to deal with the use cases in separate versions beginning with metadata
>> topic).
>> I think the asynchronous notification topic is sth. which would affect DAM uses cases but also a larger set of use-cases in general:
>> 1. Long-Running Processes 
>> a)
>> A good example was the one about long-running processes in VAM:
>> If a larger video was uploaded via CMIS then it might take some time to generate a low-res rendition of this document.
>> The server could notify the client when the renditions are available.
>> b)
>> But of course you can extend this to long-running tasks in general.
>> For example if you map your Workflows to the CMIS domain model (lets say a workflow is of base-type cmis:item) and you graphically represent the workflow
>> states in your client.
>> In this case you might want to get notified about changes without refreshing/polling the server:
>> The Client-UI updates automatically and always shows you in which step the workflow is currently in and if a manual user-action is necessary to proceed the
>> next transition.
> 
> These are good use cases.
> 
> I would add another one.  When long-running processes are taking place, it is desirable to have a "status bar" showing an estimate of the time left for completion and the fraction of the process that has been completed so far.  A callback notification (push) mechanism does not provide this, while polling (pull) mechanisms often do.  For example, a URL is returned that can be accessed to obtain an estimate of the time to completion and fraction completed.

Good catch. Getting feedback about the progress seems to be important to me.

> 
>> 2. Synchronization
>> Most of our graphic designers and photographers prefer to have a synchronized local asset archive to work with.
>> The CMIS standard has a this nice ChangeLog capability which allows you to ask for changes since the beginning or since the last processed changeToken.
>> When dealing with huge repositories this capability allows you to incrementally update the local store instead of always traversing the whole repository and
>> ask every folder/file if it has changed.
>> As we mostly have bigger CMIS repositories with hundreds of GB of assets this incremental approach is the only one which is working for us.
>> Anyway with an event subscription model we still could improve this process and reduce the traffic:
>> Mainly our graphic designers/photographers only work inside a small area of the repository and metadata fields and they are not interested in changeTokens
>> not affecting this area.
>> I think it would be nice if the client would get automatically notified if sth. changed and if he could subscribe only to those change events he is
>> interested in.
>> Maybe this does not improve the process a lot but I wanted to mention it. (Though we often have problems when shootings are located in areas which do not
>> provide a good internet connection.)
>> Also I could imagine that maybe the Core/Parent CMIS TC thought about this and met problems I do not yet see.
> 
> Although this is similar to asynchronous access, it seems to be a different use case. Indeed, I would classify it as two new use cases:
> 
>  a. Filtering of the CMIS changelog.  CMIS only provides a mechanism for requesting events after a specified time.  CMIS does have a query capability, but it cannot be applied to the change log.
> 
>  b. Publish-subscribe.

You are right. I mixed up two use cases here which should be split.

> 
>> 3. Performance
>> To increase the performance of the CMIS interface I mainly see three points:
>> a) Client side: Only use the minimum OperationContext. In other words: Only ask for this infos you need to deal with (filters, include/exclude
>> relationships/acls etc)
>> b) Server side: If the server is backed by a database: Use a 2nd-LevelCache if possible (might not always be possible because external applications might
>> also update the DB and bypass the persistence layer which holds the cache)
>> c) Client side: Consider using/enabling a cache.
>> b) and c) deal with caches and both need to deal with the same problems: stale/outdated caches
>> Maybe it would be possible to automatically update the CMIS Client Cache by having such an event subscription model.
>> (If I remember right on the Apache Chemistry mailing list I noticed some requests about extending the Cache for the Java OpenCMIS Client library.
>> I think one of the problem was a maybe stale TypeDefinitionCache)
>> So in general I think it would be nice to have sth. like this (from client side view):
>> 1) Ask CMIS server for Repository Capabilities
>> 2) If capabilities includes sth. like CMIS4DAM.Notifications ask for the Event Types the Server supports
>> 3) Register/Subscribe for the Event Types you are interested in
>> 4) Handle the events properly
> 
> I can see how (1) to (3) could be supported.  For (3) one could store a cmis:item object in the repository.  I am less clear about what (4) would entail.

4) is just about implementing an EventHandler and is in scope of the client implementation.
Assumed that there is a framework like Chemistry OpenCMIS which wraps the low-level stuff an event handler for workflow completion could simplified look like:

…
    handleEvent(Event event)
    {
        String wflId = (String) event.getProperty(„workflow.id“);
	Boolean success = (Boolean) event.getProperty(„workflow.success“);
	if (success)
        {
	    updateUi(WflView, wflId, SUCCESS)
        } else
	{
	    String errorMsg = (String) event.getProperty(„workflow.error“);
	    showErrorMsg(errorMsg);
	}
    }
…

Whereby the event really could be a cmis:item (no version and/or content is necessary).

> 
>> Maybe a very naiv approach would be to, please promise not to laugh ;) … simply use the MQTT protocol for subscribing to events?
>> (Something like Capability.MQTT ???) …. not sure if this is a good idea.
> 
> I am also unsure about it being a good idea.  MQTT is a relatively low-level messaging protocol, while CMIS is a web service protocol.

yes, maybe too naiv ;)
I am a bit afraid of the low-level part (as I really seldom need to get down to that layer). Long time I always thought of Comet or Bayeux when hearing about HTTP Server Push. Today I think there is a HTML5 WebSocket available which can handle this.

> 
>> But I like the idea to slice the objectives into smaller parts which are handled in separate versions of the CMIS4DAM spec and to start with the core task
>> for 1.0: Support/Map Metadata Standards
>> I think this keeps up from getting lost in too many tasks and focuses on one issue at a time.
>> I simply wanted to introduce and fix these ideas in case they might be interesting later when we come to the async notifications issue.
>> (It is also useful for me because often after months or years I can no more remember why I thought this was a good idea ;) )
>> Cheers
>> Sascha
>> 
> 
> Best regards,
> 
> — Ken

Cheers
Sascha



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]