Further improvements - Githubissues

int-72h / pytoast

A simple, low overhead content distribution system

BSD 3-Clause "New" or "Revised" License

8 stars 2 forks source link

Further improvements #11

Closed int-72h closed 2 years ago

int-72h commented 2 years ago

AKA the todo list.

[ ] Sort out schema (UUIDs, hashing etc)
[ ] Compression algorithm since lzma for that many files is really slow
[ ] genericize it (just toast, not OFtoast since frontend devs be frontending) and create a shoddy backronym for toast
[ ] Signing support possibly
[ ] make it "suck less", optimisations and unbodging (not suckless though I'm not writing this in C)

AyeTSG commented 2 years ago

Howdy, recently found out about Toast due to it's use in the OpenFortress sourcemod. I was wondering how a toast client goes about determining if local files differ from latest. Does it just hash the local file? If so, wouldn't that take a long time? Perhaps a better system could be implemented, such as a file that lists what version each local file is on?

int-72h commented 2 years ago

Howdy, recently found out about Toast due to it's use in the OpenFortress sourcemod. I was wondering how a toast client goes about determining if local files differ from latest. Does it just hash the local file? If so, wouldn't that take a long time? Perhaps a better system could be implemented, such as a file that lists what version each local file is on?

This was the initial approach. This todo list is a bit out of date. On the client I believe no hashing is done, and on the toaster we're using md5's which are quite fast.