NETRAVE/lib/pkg/sumdb/sum.golang.org/latest

go.sum database tree
19688221
k58/ugqvqq6DqYjvo1m1COmAGb067rn6gQNOPDdtELg=

— sum.golang.org Az3grhYRJ7p1GIdTipHl5Sqe55vwSI8JugOEHx10umcUxmC5CFJxCpjrU3SFPAnm1YuxAZ3TqifbpfWXZncfjYtidgY=
Update changelog, add go latest file 2023-07-30 21:15:50 -06:00			`go.sum database tree`
There's a lot here... So, let's get into it. First, we are straying from the in-memory ideation of storing all our pcap chunks in the memory I fear that we might bottle up the ram if we depend solely on it. So, i've made things default to sqlite flatfile, with the option for both remote and in memory This way, dependant on the users needs, they can use a different implementation. That's why the creation of a great deal of files and an entire new directory space I've almost finished implementing the database system into itself, but I want the DB system to be largely independent of the rest of the system. Because, you know me, I am a fan of encapsulation. and I like making software coded to be independent. Yes, if the rest of the system isn't working, the database has nothing to docker but at least it makes the system more robust, if even a major system can collapse, and the system as a whole remains functional. Philisophically, I find this is largely lacking in modern software, and I believe that these practices will see the protohandler performing much better than we would expect Since this system as a whole will be independent of the main NETRAVE system, it opens the door for further expanding, or perhaps even completely repurposing this protocol going forward. 2023-10-02 15:31:36 -06:00			`19688221`
			`k58/ugqvqq6DqYjvo1m1COmAGb067rn6gQNOPDdtELg=`
Update changelog, add go latest file 2023-07-30 21:15:50 -06:00
There's a lot here... So, let's get into it. First, we are straying from the in-memory ideation of storing all our pcap chunks in the memory I fear that we might bottle up the ram if we depend solely on it. So, i've made things default to sqlite flatfile, with the option for both remote and in memory This way, dependant on the users needs, they can use a different implementation. That's why the creation of a great deal of files and an entire new directory space I've almost finished implementing the database system into itself, but I want the DB system to be largely independent of the rest of the system. Because, you know me, I am a fan of encapsulation. and I like making software coded to be independent. Yes, if the rest of the system isn't working, the database has nothing to docker but at least it makes the system more robust, if even a major system can collapse, and the system as a whole remains functional. Philisophically, I find this is largely lacking in modern software, and I believe that these practices will see the protohandler performing much better than we would expect Since this system as a whole will be independent of the main NETRAVE system, it opens the door for further expanding, or perhaps even completely repurposing this protocol going forward. 2023-10-02 15:31:36 -06:00			`— sum.golang.org Az3grhYRJ7p1GIdTipHl5Sqe55vwSI8JugOEHx10umcUxmC5CFJxCpjrU3SFPAnm1YuxAZ3TqifbpfWXZncfjYtidgY=`