<snip> Because I developed my own encryption API which uses AES256 but has a couple tricks. SSL certs will not suffice, and the whole point to having my own encryption technique is so that I can avoid SSL certs and the process of registering them and installing them.
Because I am encrypting the file data before sending, I have to base64encode the data before sending over the wire, unless someone has a better suggestion for how to format the data in an internet friendly way. Also I don’t really have any experience in setting up web servers, and since I am developing this for the company I work for, they will likely not want this running on a different server than they already use which is MS SQL, and probably won’t want it running on their mission critical servers either. After going back and forth with Mark, I see that I am going to have to break the data up anyway, so I am going to send an array first which has all the information I need to control the server side (things like versioning, extended paths, workflow stuff etc.) and then send each file separately using whatever method works best. I am not averse to sending the file size first. Bob S On Feb 25, 2025, at 10:03 AM, Richard Gaskin via use-livecode <use-livecode@lists.runrev.com> wrote: This excercise raises a question: rather than invent another protocol, why not use HTTP? Saves dev time, eliminates the need to write and maintain documentation for a custom protocol, leverages existing robust tooling, allows for integration with other packages as customer needs evolve, and stakeholders often get to buy-in faster where open standards are employed. -- Richard Gaskin FourthWorld.com<http://fourthworld.com/> _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
