Logon Request - Device to Server
The logon request is the device authentication request. This is what the device sends to the server to request authentication and profile information.
<logon>
<uid>
user authentication id
</uid>
</logon>
Logoff Notice - Device to Server
This is the notice that a device will send to a server to indicate that its user has left the device, and that the device should no longer be tagged as being associated with the user. NOTE! If there are any remaining outstanding notices that needs to be sent to the server first before issuing this logoff request. Otherwise, changes will be lost.
<logoff>
<uid>
user authentication id
</uid>
</logoff>
Logon Reply - Server to Device
This is the notice that the server will send either acknowledging or rejecting the authentication request. If the device receives a confirmation, it means that the device is not associated with the authenticated user.
<logon>
<uid>
user authentication id
</uid>
<ack>
boolean 'true' or 'false'
</ack>
</logon>
Snapshot Request - Device to Server
This is sent by devices to the server to request a DB select of a data set. The server will then send back the selection of the profile data set that the application wants. This allows us to optimize the network traffic so that devices only get the sets that they are interested in.
<snapshot>
SQL structured data set, used for the DB SELECT, wrapped inside application identifier tags.
</snapshot>
Snapshot Reply - Server to Device
This is the server's reply to a device for a requested profile selection. Note that the server will beam down EVERYTHING for the selected set, regardless of whether or not the device supports some of the data elements. It is the job of the device to use the data it is capable of handling, and ignoring the data it cannot interpret. This allows the profile to grow in complexity without requiring specific configuration on the server for what each device is capable of.
<snapshot>
SQL structured data set containing the selected information, wrapped inside application identifier tags.
</snapshot>
Data Update - Device to Server
This packet is sent by devices to the server to indicate that a data update has taken place. Within the tag should be the application tag along with the DB structured data to update. Applications should only send information that has changed. Because each entry for each application has a unique ID, a DB update can be called to modify the changed fields. This just prevents the need to beam whole copies of an entry.
<update>
<mode>
exclusively one of the following: 'add' 'modify' 'delete'
</mode>
SQL structured data, wrapped inside application identifier tags.
</update>
Data Sync - Server to Device
This packet is sent by the server to devices to synchronize them with newly updated data from other devices.
<synch>
<mode>
exclusively one of the following: 'add' 'modify' 'delete'
</mode>
SQL structured data, wrapped inside application identifier tags.
</synch>
Todo Application
<todo_app>
<id> </id>
<done> </done>
<priority> </priority>
<text> </text>
</todo_app>
Memo Application
<memo_app>
<id> </id>
<filename></filename>
<text> </text>
</memo_app>
Message Application
<message_app>
<id> </id>
<fromid> uid of the sender </fromid>
<from> string name of the sender </from>
<text> </text>
</message_app>
Calendar Application
<calendar_app>
<id> </id>
<date> </date>
<begin> </begin>
<end> </end>
<text> </text>
</calendar_app>
Contact Application
<contact_app>
<id> </id>
<uid> unique system uid of the individual </uid>
<fname> </fname>
<lname> </lname>
<company> </company>
<worktel> </worktel>
<hometel> </hometel>
<mobile> </mobile>
<pager> </pager>
<workaddr> </workaddr>
<homeaddr> </homeaddr>
</contact_app>