| 1 |
"Alec Warner" <antarus@g.o> writes: |
| 2 |
|
| 3 |
> That being said I still don't see the usefulness here. |
| 4 |
> |
| 5 |
> You seem to think that using the existing APIs for this data is wrong, |
| 6 |
> and I think the opposite, so I guess we will agree to disagree on this |
| 7 |
> matter. |
| 8 |
|
| 9 |
Yeah I still think that there is no point in requiring using of a |
| 10 |
specific API when the same data can easily be available in a format that |
| 11 |
is more or less parsable with ease in any modern (and non) programming |
| 12 |
language. |
| 13 |
|
| 14 |
Beside, I find expanding the HOMEPAGE syntax to allow more than one link |
| 15 |
a bit ... overkill, if the same thing can be achieved in metadata.xml... |
| 16 |
|
| 17 |
>> Beside, if you really want to go down that road you should be counting |
| 18 |
>> that beside ReiserFS with tail, I don't remember any other Linux FS that |
| 19 |
>> has block smaller than 512bytes, which means that each file in metadata |
| 20 |
>> cache is taking up much more than just its size in characters. |
| 21 |
>> |
| 22 |
>> All your math is thus wrong. |
| 23 |
> |
| 24 |
> As was pointed out on IRC, UTF8 characters are not a fixed size, |
| 25 |
> making my math even more wrong ;) |
| 26 |
|
| 27 |
If we consider HOMEPAGE, the assumption that characters are fixed size |
| 28 |
to 1 byte is good enough; URLs are usually encoded in pure ascii |
| 29 |
character space for compatibility; while IDN would break that |
| 30 |
assumption, we can't even assume that IDN is always available and so on. |
| 31 |
|
| 32 |
For description maybe it's different because there is space there for |
| 33 |
UTF-8 characters, but that's going to bring us even farthest than the |
| 34 |
point. |
| 35 |
|
| 36 |
-- |
| 37 |
Diego "Flameeyes" Pettenò |
| 38 |
http://blog.flameeyes.eu/ |
Archives