|
1 | | -# epicsVTypeJava |
2 | | -A set of interfaces and utilities to work with EPICS types in Java |
| 1 | +# gpClient |
| 2 | + |
| 3 | +The generic purpose client is meant to be used to build applications that |
| 4 | +are not specific to a particular deployment environment or to a particular use |
| 5 | +case. It provides a system of queuing and caching that is appropriate |
| 6 | +in most instances of multi-threaded applications. It isolates each reader |
| 7 | +and writer and therefore protects different parts of the applications. |
| 8 | +As such, it is not suitable for all purposes. |
| 9 | + |
| 10 | + |
| 11 | +You **WILL** want to use the gpclient if: |
| 12 | + |
| 13 | +You want data access and do not care about protocol details |
| 14 | +You want something thread-safe without having to care about locks and race conditions |
| 15 | +You want to mix data from multiple sources (i.e. other protocols, databases, files, etc.) |
| 16 | +You are developing a user interface |
| 17 | +You are developing an extensible application where different user will |
| 18 | +want data access |
| 19 | + |
| 20 | + |
| 21 | +You may **NOT** want to use the gpclient if: |
| 22 | + |
| 23 | +You need low level access to the EPICS communication protocol |
| 24 | +You need to implement an application specific real-time engine |
| 25 | +You want to lock the protocol until you have processed the data |
| 26 | +All your reads/write are tightly coupled to each other |
| 27 | + |
| 28 | + |
| 29 | +The generic purpose client provides the following functionality: |
| 30 | + |
| 31 | + |
| 32 | +* A client API that is always thread-safe |
| 33 | +the ability to specify on which thread or thread pool the notification |
| 34 | +should happen |
| 35 | +* A pluggable way to connect to different publish/subscribe sources of |
| 36 | +data (i.e. {@link DataSource}) |
| 37 | +* The ability to create your own data channel implementations, even if |
| 38 | +they do not follow the common patterns |
0 commit comments