20 Oct, 2010, David Haley wrote in the 21st comment:
Votes: 0
Rudha said:
If you read the thread that I was quoting that from, the problem is that file access is restricted by the sandbox. Using the database, however, is not, and therefore provides a work-around, though not entirely an optimal one.

I've been trying to tell you in several posts that the sandbox has been changed significantly and basically removed entirely; KaVir said the same. Even back when it existed, users could remove restrictions if they wanted to, allowing file access. You should look into the changes…

Anyhow, the point here is that the sandbox is no longer an issue for storing files on the file system. So the technical problem here has been solved.

Rudha said:
I really shouldn't have to explain the difference between having the data stored as files in a filesystem and having them as blob fields in a database.

I didn't say that they were the same thing. I said that they both accomplish the same goal. The point is to ask what other goal is accomplished by having actual files rather than stored images. It doesn't really matter in light of the above, but nonetheless I wasn't trying to say something quite so silly as you seem to believe. :smile:
21 Oct, 2010, Rudha wrote in the 22nd comment:
Votes: 0
Realising that KaVir's post in the MC forums has resulted in a sandbox change, try to take the following post with a grain of salt. Nonetheless, I feel I would be remiss if I didnt explain where I was coming from with the database vs. filesystem topic.

David, you were speaking of the two as if they were functionally equivalent, and they're not. You are correct in saying that you accomplish the same goal doing them, but the database method comes with the fact that you have to deal with the database overhead to manipulate the images, whereas if you have them in the filesystem its much simpler. So, essentially: they achieve the same goal, but in different ways, with different tradeoffs.

Say, for example, that I want to implement an easy way for a builder to upload an image for a given avatar to the MUD and consequentially to people who view that NPC/monster/kitchen sink/whatever. This would mean that I either have to develop some sort of interface to the database to manipulate the database locally (and then be able to DIFF the changes between the client/server) or, alternatively, upload the file from the filesystem to the server, and then back to the database and save it. Whereas if I have a client filesystem and server filesystem, I can just compare the files in the two systems. (If you want to get real fancy, you could use a SVN/Git/CVS-ish system, but that seems overkill to me)

That said, again with the sandbox changes it becomes a moot point, but I felt it neccesary to elaborate where I was coming from, especially since I do intend to develop some sort of OLC to edit the graphical elements, as opposed to hardcoding them.

Maya/Rudha
21 Oct, 2010, David Haley wrote in the 23rd comment:
Votes: 0
All I was trying to say is that they accomplished the same goal, a point we seem to agree upon. Other things like "functionally equivalent" are not words that I used, but in fact are your choice of words driven by how you interpreted my post. Allow me to take a moment to observe that without a hint of bad faith on your part, a small and innocent misinterpretation resulted in a misunderstanding, and there is no need to get upset, call each other names or accuse each other of malicious behaviour. Asking for clarification is always a safe and productive solution. So perhaps let us keep this in mind for the future, to extend a little more kindness before we start bringing out name-calling guns.

I still am not really sure what the big difference is with respect to the use cases you gave. For example, any image manipulation requires the image to be in memory. Whether that happens from loading a file into memory, or moving a blob from a DB to your program's memory, seems to be incidental to me. E.g.,
unsigned char* imgData = read_from_file("c:/my/path/somewhere/on/disk/foo.png")

vs.
unsigned char* imgData = read_blob_from_db("foo_img", "my_img_db.sqlite")


As for diffing, I'm not sure that a diff of binary data would be that useful. In fact, most standard diff programs simply tell you that the binary files are different, and that is that:
$ diff IMG_2477.JPG IMG_2478.JPG
Binary files IMG_2477.JPG and IMG_2478.JPG differ

For revision control, every VCS that I know of doesn't bother trying to store diffs for binaries and just stores the whole thing each time.

As for uploading, if your client plugin (since we're talking about MUSHclient here) is sending the image to the server over the MUD channel, it has to have it in memory first, putting us back in the case above where you're writing from a buffer and whether that buffer comes from a file or a database is just a one-liner API call in either case.

I understand that filesystems are more familiar to most people, and that might, in and of itself, be a good enough reason to use them. I'm only interested in the technical aspects of the question in what I have been saying.
20.0/23