Move configuration files to cfg folder

And leave datas for runtime-generated files only

Kilandor	#31930 07.12.2011 22:57
Administrators Поблагодарили: 9 раз	Well I think a file api would be fine and a good idea as a basis. I think some of the things described are a bit overkill and will not matter to a majority of users. I would also go so far as to take the base of the idea so that the API would do its folder structure based upon the module/plugin. So say I have a plugin for image uploads and then another for Videos. It would be like datas/raw/images or datas/raw/video . This will allow for quick cleanup say on removal. I started to think the api should not have a database and the module/plugin should handle it but I changed my mind. The api should have a database. It should also include identifiable to mod/plug and user as well. So the files can still be identifiable on the backend but need not be for the actual file such as is now 1-Foo.png I do not think that we need expoential folders and limit to the number of files in these. It would require tracking or something else. Just for example Mediawiki simply uses the first 2 characters from the MD5 of the file name. It does not expoentially have folders Of course we can use PHP hashing system to hash the uploaded file completly. Relative to size of the file and what not this could very easily fail on servers/hosts depending on the size of the file. So I think hashing off the file name is the only logical choice. This would still let you know the path/name though. So likely appending the timestamp to the filename simply for the purpose of generating the hash would be appropriate. I think this should be a seperate issue for the file handling, I think simply for the task at and and per the topic that the cfg should be moved. This way things like extension/mimetype can have our cotonti system defaults, which can be overridden by or added to by custom configs in the cfg folder.

Kilandor

#31930 07.12.2011 22:57

Well I think a file api would be fine and a good idea as a basis. I think some of the things described are a bit overkill and will not matter to a majority of users.

I would also go so far as to take the base of the idea so that the API would do its folder structure based upon the module/plugin. So say I have a plugin for image uploads and then another for Videos. It would be like datas/raw/images or datas/raw/video . This will allow for quick cleanup say on removal.

I started to think the api should not have a database and the module/plugin should handle it but I changed my mind. The api should have a database. It should also include identifiable to mod/plug and user as well. So the files can still be identifiable on the backend but need not be for the actual file such as is now 1-Foo.png

I do not think that we need expoential folders and limit to the number of files in these. It would require tracking or something else. Just for example Mediawiki simply uses the first 2 characters from the MD5 of the file name. It does not expoentially have folders

Of course we can use PHP hashing system to hash the uploaded file completly. Relative to size of the file and what not this could very easily fail on servers/hosts depending on the size of the file.

So I think hashing off the file name is the only logical choice. This would still let you know the path/name though. So likely appending the timestamp to the filename simply for the purpose of generating the hash would be appropriate.

I think this should be a seperate issue for the file handling, I think simply for the task at and and per the topic that the cfg should be moved. This way things like extension/mimetype can have our cotonti system defaults, which can be overridden by or added to by custom configs in the cfg folder.