|
| Name | Description | ||
| ChanClose | Callback - called by the framework when there channel was closed. | |||
| ChanOpen | Callback - called by the framework when there channel was opened. | |||
| Content | property Content | |||
| Enabled | Determines if this profile can be used. | |||
| Encoding | Holds profile Encoding parameter. | |||
| Receive | Callback - called by the framework when there's a message to be received by this profile. | |||
| Send | Sends the message using this profile. | |||
| Tuning | Determines if this is a tuning profile. | |||
| TuningReceive | Callback - called by the framework when there's a data received. | |||
| TuningSend | Callback - called by the framework before data is sent. | |||
| URI | Holds profile URI information. |
BeepProfile is probably the most interesting interface you should deal with when you use Beep protocol. You can easily ignore underlying structure of Beep protocol, and just focus on your own profile - one you really need. If you implement your own profile, you should implement above methods/properties. You should parse received Messages the way you want, and perhaps provide additional properties/methods/events for your application that exactly suit your needs. On the other hand, when message needs to be sent on remote side, you can read from properties you provided to the application, structure it somehow to BeepMessage and just send over the transport. That's it! If you use predefined profiles, such as Syslog, ZIP or other, you should be aware of their capabilities. For example, Syslog profiles will fire events when data arrives. Internally, it will parse received message and provide event for each Syslog-related message. This is something you should do when you define your own profile - just the way it suits you the best.
|