Difference between revisions of "Protocols/OSCAR/Foodgroups/BART"
| Line 8: | Line 8: | ||
{{Protocols/OSCAR/Foodgroups/BART/Description}} | {{Protocols/OSCAR/Foodgroups/BART/Description}} | ||
| + | |||
| + | For some items, the actual assets are downloaded using the BART system and in other cases, just descriptive XML files are used. Once a BART item is downloaded, it is basically cached FOREVER by the client, so updating requires publishing a new BART item. This is especially important when the BART item is an asset. When the BART item is a descriptive XML file, only the XML file is cached forever and any assets it refers to can use different caching schemes determined by the client. | ||
| + | |||
| + | All BART items are represented by a BART ID. A BART ID is a 5 byte to 20 byte binary value that represents the BART item and is sent around by the client and the servers. One simple way to think of the BART ID is as a compressed URL. When the client receives a BART ID, either from another client or from the server, it checks its cache or uses the BART server to download the item. The BART server also has a cache and connects to the various partners to download the assets if it does not have them. It is expected that each BART ID points to a unique item. The backend will collapse duplicate items into a single ID. The BART server also will store custom items for some asset types. | ||
| + | |||
| + | Having a Buddy icon with opaque data of 0x0201d20472 means the user has explicitly chosen to have no Buddy icon. This is different then not having a Buddy icon. This ID should be treated specially and does not need to be fetched from BART (although BART will return an empty GIF). This was done so clients could tell when they upgraded from old style Buddy icons to BART Buddy icons. This special ID should NOT be used for other BART types. | ||
| + | |||
{{Protocols/OSCAR/Foodgroups/BART/SNACs}} | {{Protocols/OSCAR/Foodgroups/BART/SNACs}} | ||
Revision as of 05:17, 22 March 2020
| OSCAR Protocol |
| Introduction • Terms • Clients |
| Basic |
| Datatypes • FLAP • SNAC • TLV |
| UUIDs • Errors • Tool IDs |
| Host Interaction |
| Rate Limits • Migration • Messages |
| Other Services |
| ADMIN • ADVERT • ALERT |
| BART • BOS • BUCP • CHAT |
| CHAT_NAV |
| Tutorials |
| Sign On • BART • Rendezvous |
| ICBM • Locate • Buddies |
| Foodgroups |
| OSERVICE (0x0001) |
| LOCATE (0x0002) |
| BUDDY (0x0003) |
| ICBM (0x0004) |
| ADVERT (0x0005) |
| INVITE (0x0006) |
| ADMIN (0x0007) |
| POPUP (0x0008) |
| PD (0x0009) |
| USER_LOOKUP (0x000A) |
| STATS (0x000B) |
| TRANSLATE (0x000C) |
| CHAT_NAV (0x000D) |
| CHAT (0x000E) |
| ODIR (0x000F) |
| BART (0x0010) |
| FEEDBAG (0x0013) |
| ICQ (0x0015) |
| BUCP (0x0017) |
| ALERT (0x0018) |
| PLUGIN (0x0022) |
| UNNAMED_FG_24 (0x0024) |
| MDIR (0x0025) |
| ARS (0x044A) |
| ID | Name | Service | Status | Version |
|---|---|---|---|---|
| 0x0010 | BART | BOS | Active | 1.9 |
The Buddy Art, or BART, server provides access to the client for downloading image, sound, and xml assets for expressions for their buddies and themselves. Examples of BART items include Buddy icons, Buddy arrival sounds, and immersive wallpapers.
For some items, the actual assets are downloaded using the BART system and in other cases, just descriptive XML files are used. Once a BART item is downloaded, it is basically cached FOREVER by the client, so updating requires publishing a new BART item. This is especially important when the BART item is an asset. When the BART item is a descriptive XML file, only the XML file is cached forever and any assets it refers to can use different caching schemes determined by the client.
All BART items are represented by a BART ID. A BART ID is a 5 byte to 20 byte binary value that represents the BART item and is sent around by the client and the servers. One simple way to think of the BART ID is as a compressed URL. When the client receives a BART ID, either from another client or from the server, it checks its cache or uses the BART server to download the item. The BART server also has a cache and connects to the various partners to download the assets if it does not have them. It is expected that each BART ID points to a unique item. The backend will collapse duplicate items into a single ID. The BART server also will store custom items for some asset types.
Having a Buddy icon with opaque data of 0x0201d20472 means the user has explicitly chosen to have no Buddy icon. This is different then not having a Buddy icon. This ID should be treated specially and does not need to be fetched from BART (although BART will return an empty GIF). This was done so clients could tell when they upgraded from old style Buddy icons to BART Buddy icons. This special ID should NOT be used for other BART types.
| Subgroup | Origin | Name |
|---|---|---|
| 0x0001 | Any | BART__ERR |
| This is the error SNAC for the BART foodgroup. | ||
| 0x0002 | Client | BART__UPLOAD_QUERY |
| This SNAC uploads a custom item to the BART host. Only certain types allow custom items. | ||
| 0x0003 | Host | BART__UPLOAD_REPLY |
| These are the results for an item requested with BART__UPLOAD_QUERY. | ||
| 0x0004 | Client | BART__DOWNLOAD_QUERY |
| Legacy request buddy icon from host. | ||
| 0x0005 | Host | BART__DOWNLOAD_REPLY |
| Legacy host response to a buddy icon request. | ||
| 0x0006 | Client | BART__DOWNLOAD2_QUERY |
| This SNAC downloads an asset from the BART host. | ||
| 0x0007 | Host | BART__DOWNLOAD2_REPLY |
| These are the results for an item requested with BART__DOWNLOAD2_QUERY. | ||
