[gagar]

Hi there,

I'd like to propose a patch for otherfunctions.cpp so that eMule can recognize additional file formats. The rationale is to give the users the ability to find and share more files which are also free formats that are not DRM infested -- it's not as if I weren't a bit disappointed because the Theora files I post to the contentdb cannot be easily found with a search on the network The "new" formats are mainly .ogv, .webm and OpenOffice.org/LibreOffice formats, but the patch itself is self-explanatory and can provide more information. A very similar patch got committed in aMule, it may get committed in eMule Plus if its devs accept it and Shareaza already recognizes many of these formats, so IMHO with eMule it could benefit the entire network.

Here's an archive containing the patch and a modified otherfunctions.cpp (encoded in UTF-8, with Windows line endings (CR+LF)). For your convenience, here's the patch and the modified otherfunctions.cpp in plain text form. In case it would have changed since 050a, please note that I copied otherfunctions.cpp from the source code archive of emule 0.50a.

Hope you'll find this useful in some way.

[starko]

And what about all other formats? ePUB, Mobi etc

While this is a good idea, the suggested implementation treats symptoms only. It's like having new servers hard coded in the source code.

The problem is not that there are new formats that need to be added, but that new formats appear constantly.

There should be a way to add new file types and formats without having to wait for the next version of eMule to be patched. For example as a file that can be edited - for example as ini file or as comma separated values.

That would liberate developers from manually updating file types and formats every time the world evolves. Also that would allow users have their own custom file types dropdowns.

This post has been edited by starko: 24 June 2011 - 08:55 AM

[pier4r]

starko, on 24 June 2011 - 10:19 AM, said:

And what about all other formats? ePUB, Mobi etc

While this is a good idea, the suggested implementation treats symptoms only. It's like having new servers hard coded in the source code.

The problem is not that there are new formats that need to be added, but that new formats appear constantly.

There should be a way to add new file types and formats without having to wait for the next version of eMule to be patched. For example as a file that can be edited - for example as ini file or as comma separated values.

That would liberate developers from manually updating file types and formats every time the world evolves. Also that would allow users have their own custom file types dropdowns.

Great idea, and it is also "simple" (because a file parser is a simple task to do). The problem is:
- is boring
- an user can use (anyway is a less accurate fashion) the advanced search tags to find specifics formats (from http://forum.emule-p...dpost&p=1064445 ), e.g: @ext=mobi,epub,emulecollection

[starko]

I wonder why file types/formats were not implemented in preferences.ini?

[FileTypes]
Audio            =aac,wma,xm,...,mp3,wav
Video            =3g2,3gp,...,wmv,xvid
Image            =bmp,emf,...,wmp,xif
Archive          =7z,ace,...,zip,zoo
Program          =bat,cmd,exe,...,wsh
CD_Image         =bin,bwa,...,toast
Document         =chm,css,...,xml
eMule_Collection =emulecollection

Was there any reason for the current hardcoded way?

This post has been edited by starko: 25 June 2011 - 09:59 PM

[pier4r]

starko, on 25 June 2011 - 11:54 PM, said:

I wonder why file types/formats were not implemented in preferences.ini?

[FileTypes]
Audio =aac,wma,xm,...,mp3,wav
Video =3g2,3gp,...,wmv,xvid
Image =bmp,emf,...,wmp,xif
Archive =7z,ace,...,zip,zoo
Program =bat,cmd,exe,...,wsh
CD_Image =bin,bwa,...,toast
Document =chm,css,...,xml
eMule_Collection =emulecollection

Was there any reason for the current hardcoded way?

I think only laziness. I repeat, it should be quite simple especially if the types are fixed (audio, video, image, etc..)

[starko]

pier4r, on 26 June 2011 - 11:40 AM, said:

I think only laziness.

I don't think it was laziness. Or lack of experience or skill. Probably more like low priority at the time when there were so many other important or exciting things to do. But if there is some other, not obvious yet very important reason... i'd like to know what it is.

pier4r, on 26 June 2011 - 11:40 AM, said:

... especially if the types are fixed (audio, video, image, etc..)

To me, not only they don't have to be fixed, this way the ability to customize/personalize the types is ESPECIALLY attractive. Add new narrow categories like "eBooks" or combine some formats from different types, etc

Win32 api function read_inifile_section() returns all the entries in a SECTION of an INI file as a list of key value pairs. So you just iterate through all the pairs, do localization of the name, populate your "Type" dropdown and voila... probably 10 lines of code at most.

This post has been edited by starko: 26 June 2011 - 05:26 PM

[torpon]

And why types should be fixed but formats should be open?
"I think" don't look like a solid argument to talk about laziness.

Cheers

[pier4r]

torpon, on 26 June 2011 - 02:30 PM, said:

And why types should be fixed but formats should be open?
"I think" don't look like a solid argument to talk about laziness.

Cheers

Because with free types and formats the operation is more complex/boring (for example, adjust lists).

Anyway every sentence on a forum is a personal sentence, with an implicit "i think", so none is solid here

This post has been edited by pier4r: 27 June 2011 - 04:16 PM

[gagar]

starko, on 24 June 2011 - 08:19 AM, said:

And what about all other formats? ePUB, Mobi etc

I tried to be as conservative as possible and since I don't know much about ebook formats, I simply didn't want to mess with them (I just got my hands on my first Android phone, by default it comes without a file manager (!) After rooting it and installing Cyanogen, I guess I'll give a try to epub files but for the time being, I'm just not familiar with them).

If I were the one to make the decision, I would happily trash DRM infested wma and vmw formats, then move cbr, cbz and cbt to documents from archive, and then check again to make sure that wma and vmw would really be dead and buried for good. So I guess restraining myself was the best option.

Quote

The problem is not that there are new formats that need to be added, but that new formats appear constantly.

There should be a way to add new file types and formats without having to wait for the next version of eMule to be patched. For example as a file that can be edited - for example as ini file or as comma separated values.

That would liberate developers from manually updating file types and formats every time the world evolves. Also that would allow users have their own custom file types dropdowns.

Such a system would be great, indeed, but unfortunately it's beyond my coding abilities. Besides, even with such a system which would give users additional possibilities, devs would still have to maintain a decent default ini file since many users simply rely on the default settings and are reluctant to change them. Hopefully this patch will help them a little bit.

[DatHebIkWeer]

Maybe there should be a way the user can select and categorize file formats that have to be treated in a certain way. I bet there will be extensions double used by different communities. In 1 community a .dat file for instance may be totally something different from a .dat file in another community.
Anything hardcoded should be avoided in this matter.

For instance i would like to set up eMule so .iso files download the first and last chunk first too (like rars and zips). So why not add a line to the preferences file to do that?