| Summary: | [docshare] add usage collection to docshare | ||
|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Scott Lewis <slewis> |
| Component: | ecf.cola | Assignee: | ecf.core-inbox <ecf.core-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | codesurgeon, dennis.vaughn, mayworm |
| Version: | unspecified | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Scott Lewis
I am not sure what the best approach would be for collecting usage information. For the usage data collector in EPP they have listeners for command executions and view/editors being activated. This is great from a generic standpoint but I dont think it really helps for docshare since it is using a dynamic approach with the roster contributions. With that being said there is an ext point for implementing a usage monitor which you can define how it gathers information. Any thoughts? (In reply to comment #1) > I am not sure what the best approach would be for collecting usage information. > For the usage data collector in EPP they have listeners for command executions > and view/editors being activated. This is great from a generic standpoint but > I dont think it really helps for docshare since it is using a dynamic approach > with the roster contributions. With that being said there is an ext point for > implementing a usage monitor which you can define how it gathers information. > > Any thoughts? > As a start, I would be inclined to just notify on starting/ending of a docshare session. It would probably not be a good idea to get into something that would get notifications of docshare messaging...with the attendant problems of listeners that could block, throw exceptions and screw things up, etc. Resolving as wontfix as no resources available. If committer and/or contributor resources become available then please reopen. |