Technical Design
A global object to describe the folder structure and store the file indexes. The whole object content is serialized as JSON and stored as a pinned file in the Telegram channel.
Example:
{
"type": "TGFSMetadata",
"dir": {
"type": "D",
"name": "root",
"children": [
{
"type": "D",
"name": "a-directory",
"children": [],
"files": [
{ "type": "FR", "messageId": 114514, "name": "file-name.png" }
]
}
]
}
}The class to describe a folder. There can be sub-folders (children) and files. The files are described with TGFSFileRef.
The class to describe the location of the actual TGFSFile body and some essential file attributes.
The idea of this class is to minimize the size of the TGFSMetadata. Because TGFSMetadata will be updated frequently, and each update results in a de-serialization, serialization and re-upload, the cost can be very high if too much information is stored in it.
Another thought behind it is sometimes not all the file detail is needed. For example, when a user executes an ls operation towards a folder, the non-relevant file information (size, updated time) will not be retrieved. But when the user executes ls towards a file, the clients will find the actual file information body (TGFSFile) using the messageId field in this object.
The class to describe file information. A file can have multiple versions (by updating a file), and the information of every version (TGFSFileVersion) is stored in this object.
Example:
{
"type": "F",
"name": "file-name.png",
"versions": [
{
"type": "FV",
"id": "d2d6bc6c-8d39-4efd-8028-2d4721ae4af3",
"updatedAt": 1145141919810,
"messageId": 114513
}
]
}The class to describe the location of the actual file content (by messageId, means https://t.me/channelId/messageId should be the link to the file). Updating a file results in another file version (the original version will not be deleted unless the user does so with a special command).