atom/icon='a'
// 'a' is a dmi
// error: 'a': not supported icon file type
client/New(){src<<'1';}
// '1' is an ogg, but will not play in DS unless it has extension .ogg
ID:108208
 Feb 4 2011, 8:29 pm
|
|||||||
Not Feasible
| |||||||
|
Feb 4 2011, 10:04 pm
|
|
Bandock
 |
Probably because without the file extension, it could be anything. It is even possible to try including non-compliant resources that have such extensions to be in there (which may not load right at all). Plus, there are resource types included that should be able to distinguish between each other.
|
File extensions exist for convenience (program associations), not to determine the type of file. In fact, DMI is based off this concept- DMIs are of course just PNGs with comments and can be opened in any image editor.
I can rename a .ogg to .derp and it will play in vlc with no problem. DM should be no different. | |
The reason VLC will play an .ogg file with a .derp extension is because basically all of these major file types come with internal structures that tell it what kind of file it really is.
The problem with doing this in DM is that the file delivery mechanism depends somewhat on knowing a file's type before it arrives. There are certain marker flags that get used in the process. This could perhaps be solved by the server and client both being able to do checking by looking at the file type internally before picking the correct type code, but that kinda gets excessive. The icon loading code does that to a small extent in that it can tell the difference between some different file types. I guess the point is this is doable but it's probably not worth the hassle. The only place I can really see this being an issue is with uploaded files. At the developer end of things, they should simply know better than to mess with the extensions. | |
LordAndrew resolved issue (Not Feasible)
| |
