Alle foto's heten het zelfde

[Sando]

Alle foto's die mensen in een Tweakers Fotoalbum zetten heten full.jpg.

Als je leuke/handige/informatieve plaatjes vanuit het forum op je computer opslaat moet je steeds een naam bedenken. Als je een browser hebt die een plaatje automatisch op kan slaan in je plaatjesfolder dan raak je eerdere plaatjes kwijt omdat ie steeds full.jpg overwrite.

Kan dat niet gewoon lekker de naam van het origineel, of de naam van de afbeelding in de database (x6FgiXzjy1cXaNvkqGTDsuPa.jpg) heten?

Ten eerste repareert dat onnodige eigenaardigheden, ten tweede is 'alles heeft de zelfde naam' semantisch onverantwoord.

thumb.jpg en medium.jpg worden op de zelfde manier gebruikt, imo ook raar maar ik heb er geen last van, de eerste persoon die thumbnails opslaat moet ik nog tegenkomen. Daarom zou je naast full.jpg ook x6FgiXzjy1cXaNvkqGTDsuPa.jpg kunnen implementeren en standaard verstrekken in de Publieke Link en GoT-code. Lijkt een simpele oplossing waardoor alles backwards-compatible is en gepostte plaatjes vanaf heden een unieke naam hebben.

Volgens mij was het netter om ipv
x6FgiXzjy1cXaNvkqGTDsuPa/full.jpg
links te hebben als
full/x6FgiXzjy1cXaNvkqGTDsuPa.jpg
maar dat is waarschijnlijk een gedoe oplossing voor een te klein probleem.

[ Voor 12% gewijzigd door Sando op 25-08-2011 00:17 ]

[mace]

Hier is een mooie HTTP-header voor, dan kan de file op de server heten wat je wil, maar als men op save as klikt, dan krijg je een filename die je kan instellen.


Content-Disposition: attachment; filename=blaat.jpg

[Xander]

mace schreef op donderdag 25 augustus 2011 @ 00:19:
Hier is een mooie HTTP-header voor, dan kan de file op de server heten wat je wil, maar als men op save as klikt, dan krijg je een filename die je kan instellen.


Content-Disposition: attachment; filename=blaat.jpg

En die filename wordt bij het T.net fotoalbum nog meegegeven ook!!



Als ik bovenstaand plaatje wil saven in Firefox 6.0 dan noemt hij die standaard al 251300.jpg. Niet full.jpg. Ik zie het probleem niet zo.

[Osiris]

Xander schreef op donderdag 25 augustus 2011 @ 00:24:
[...]


En die filename wordt bij het T.net fotoalbum nog meegegeven ook!!

[afbeelding]

Als ik bovenstaand plaatje wil saven in Firefox 6.0 dan noemt hij die standaard al 251300.jpg. Niet full.jpg. Ik zie het probleem niet zo.

Dit kan ik beamen voor IE 8.0

[DinX]

En ook in Chrome 13 krijgen ze mooi een nummertje.

[Hahn]

Hmm, dat is dan pas sinds kort? Want nog niet zo heel lang geleden kreeg ik 'full.jpg' bij het saven van plaatjes vanaf T.net fotoalbum. Maar nu krijg ik een nummertje inderdaad.

[To_Tall]

Als ik een foto selecteer uit het forum IE9 zie ik de volgende URL

http://tweakers.net/ext/f/28xsbj6DUFVOGrCmDfuS1PdD/full.jpg

full.jpg dus ;-)

[Hahn]

To_Tall schreef op donderdag 25 augustus 2011 @ 00:32:
Als ik een foto selecteer uit het forum IE9 zie ik de volgende URL

http://tweakers.net/ext/f/28xsbj6DUFVOGrCmDfuS1PdD/full.jpg

full.jpg dus ;-)

Maar doe eens rechtermuisklik » Opslaan als... Dan krijg je een andere naam en geen full.jpg.

[Osiris]

To_Tall schreef op donderdag 25 augustus 2011 @ 00:32:
Als ik een foto selecteer uit het forum IE9 zie ik de volgende URL

http://tweakers.net/ext/f/28xsbj6DUFVOGrCmDfuS1PdD/full.jpg

full.jpg dus ;-)

Da's de URL ja. Ik weet niet wat jij bedoelt met "selecteren"? Maar als je Save-as doet, krijg je gewoon de oorspronkelijke naam als 't goed is.

[Xander]

Sando schreef op donderdag 25 augustus 2011 @ 00:13:

Volgens mij was het netter om ipv
x6FgiXzjy1cXaNvkqGTDsuPa/full.jpg
links te hebben als
full/x6FgiXzjy1cXaNvkqGTDsuPa.jpg
maar dat is waarschijnlijk een gedoe oplossing voor een te klein probleem.

Hiërarchisch gezien vind ik jouw oplossing ook niet echt netter trouwens.

Hahn schreef op donderdag 25 augustus 2011 @ 00:31:
Hmm, dat is dan pas sinds kort? Want nog niet zo heel lang geleden kreeg ik 'full.jpg' bij het saven van plaatjes vanaf T.net fotoalbum. Maar nu krijg ik een nummertje inderdaad.

Voor mijn gevoel is het al jaren zo, maar daar kan ik naast zitten.

[AW_Bos]

Volgens mij is dit sinds kort.
Benieuwd hoe ze dit doen?

[Osiris]

AW_Bos schreef op donderdag 25 augustus 2011 @ 00:43:
Volgens mij is dit sinds kort.
Benieuwd hoe ze dit doen?

Met bovengenoemde header en de auto-increment-ID uit de DB?

Twee tegelijk geuploade foto's hebben een id van $id en $id+1, dus dat zal wel zo simpel geimplementeerd zijn

[ Voor 19% gewijzigd door Osiris op 25-08-2011 00:53 ]

[AW_Bos]

ah ja....

mod_rewrite + header('Content-Disposition: attachment; filename=$info['id'].jpg') + readfile()

does the trick? ?

[ Voor 13% gewijzigd door AW_Bos op 25-08-2011 01:10 ]

[Sando]

@iedereen:

Ohja! Dat is inderdaad sinds kort dan. Maar het is een ducttape oplossing die zich niet leent voor scripten.
Automatisch opslaan gebruikt gewoon de URL, full.jpg dus.

[rob_erwt]

Het is geen ductape oplossing, maar de manier om het goed aan te bieden. Dat het bij automatisch opslaan (hoe eigenlijk? extern scripting iets?) fout gaat, zegt maar over die methode dan over hoe wij het aanbieden.

[Sando]

Had het eerst met een firefoxplugin, weet niet meer welke, geen relaxte browser.
Nu doe ik het zelfde in Opera rechtsklik menu:

code:

[Image Link Popup Menu]
Item, "Save Image" = Copy image address & Execute program, "sh"," -c python wget.py %c"

Wget houdt geen rekening met ducttape-headers. Een bestandsnaam hoort namelijk gewoon in de url te staan.

[Zerora]

Ik zou eigenlijk liever zien dat de originele bestandsnaam wordt gebruikt en niet dat codedingetje. Dat maakt het voor een hoop dingen veel makkelijker.

[Erkens]

Sando schreef op donderdag 25 augustus 2011 @ 09:37:
Wget houdt geen rekening met ducttape-headers. Een bestandsnaam hoort namelijk gewoon in de url te staan.

ducttape-header? sorry hoor, maar de bestandsnaam hoeft helemaal niet in de url te staan.

Maargoed, in dit geval is het wget die het "fout" doet, maar als je de optie --content-disposition gebruikt voor wget, dan werkt het wel.

[mace]

Het is m.i. een prima oplossing, en als je de boel leeg wil trekken met scripts dan moet je dat zelf weten maar dan is het niet zo heel moeilijk om ook die header te gebruiken.

edit:

Gewoon:

ivo@pauperbak:~$ curl -O http://tweakers.net/ext/f/28xsbj6DUFVOGrCmDfuS1PdD/full.jpg
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 18839    0 18839    0     0   303k      0 --:--:-- --:--:-- --:--:--  707k

Wordt full.jpg

Met -J (kort voor --remote-header-name )

ivo@pauperbak:~$ curl -O -J http://tweakers.net/ext/f/28xsbj6DUFVOGrCmDfuS1PdD/full.jpg
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 18839    0 18839    0     0   291k      0 --:--:-- --:--:-- --:--:--  681k
curl: Saved to filename '251300.jpg'

edit2: En DownThemAll ondersteunt de header ook.

[ Voor 71% gewijzigd door mace op 25-08-2011 23:48 ]

[Sando]

mace schreef op donderdag 25 augustus 2011 @ 23:42:
als je de boel leeg wil trekken met scripts

Als je graag lippenstift draagt moet je dat zelf weten (blijkbaar hebben we afgesproken dat we mekaar woorden in de mond mogen leggen) maar ik nomineer jou voor de flauwerpower award.

Erkens schreef op donderdag 25 augustus 2011 @ 09:45:
[...]
in dit geval is het wget die het "fout" doet, maar als je de optie --content-disposition gebruikt voor wget, dan werkt het wel.

Hey bedankt ik zal die eens proberen.

Anyway, gewoon even ter point-of-view, het url geeft de resource van een location. De resource is dus full.jpg. Als je een truukje nodig hebt om de resource te hernoemen, dan is dat gewoon een duct-tape oplossing. En dat is imo gewoon niet netjes.

Duct tape is heel populair, wordt heel veel gebruikt. Maar noem het geen chirurgisch staal.

Net zoals

code:

echo -e "Ik\nmaak\nhier\ngebruik\nvan"

-e is geen officiële sh flag en in sommige distro's werkt het niet.
Dan kan je wel zeggen dat gebruikers scripts moet aanpassen met variabelen, maar je kunt ook geen -e gebruiken to begin with.

Zerora schreef op donderdag 25 augustus 2011 @ 09:43:
Ik zie eigenlijk liever zien dat de originele bestandsnaam wordt gebruikt en niet dat codedingetje.

Helemaal mee eens, maar dan moet de boel omgegooid worden. Ik dacht, als ik een simpel backwards-compatibel voorstel doe, is er misschien een paar procent kans dat er oor naar is.

[Osiris]

Sando schreef op vrijdag 26 augustus 2011 @ 07:46:
[...]
Net zoals

code:

echo -e "Ik\nmaak\nhier\ngebruik\nvan"

-e is geen officiële sh flag en in sommige distro's werkt het niet.
Dan kan je wel zeggen dat gebruikers scripts moet aanpassen met variabelen, maar je kunt ook geen -e gebruiken to begin with.

`echo` is gewoon een stand-alone programma hoor. Mét `-e`. Dat jouw shell het tof vindt om het wiel tweemaal uit te vinden door er z'n eigen ingebouwde draai aan te geven, tja, kut voor je, eigen keus als `-e` vervolgens niet werkt hoor

Overigens vind ik het wel enorm gemierenneuk nu hoor. De `path` van een URL hoeft helemaal niet per se de file-name aan te geven. Dat maak jij d'r nu gezellig van omdat jou dat nu mooi uitkomt. Maar in werkelijkheid zegt 't hooguit iets over de vindplaats van een bepaalde resource.

[ Voor 19% gewijzigd door Osiris op 26-08-2011 08:07 ]

[Erkens]

Sando schreef op vrijdag 26 augustus 2011 @ 07:46:
Anyway, gewoon even ter point-of-view, het url geeft de resource van een location. De resource is dus full.jpg.

Strict gezien bevat een URL geen bestandsnaam, alleen een path naar een bepaalde resource, dat deze in dit geval full.jpg is genoemd en jij denkt dat het om een filename gaat doet daar niks van af.

scheme://domain:port/path?query_string#fragment_id

[Sando]

Osiris schreef op vrijdag 26 augustus 2011 @ 08:01:
[...]

`echo` is gewoon een stand-alone programma hoor. Mét `-e`. Dat jouw shell het tof vindt om het wiel tweemaal uit te vinden door er z'n eigen ingebouwde draai aan te geven, tja, kut voor je, eigen keus als `-e` vervolgens niet werkt hoor

Wat weer een typische tweaker-reactie. Doe eens niet mij persoonlijk aan te vallen. Ik heb geen shell geprogrammeerd. -e is een populaire persoonlijke draai van iemand anders die niet officiëel in sh zit.

echo is een language construct, en veel compacte versies van linux hebben geen /bin/echo.

Overigens vind ik het wel enorm gemierenneuk nu hoor. De `path` van een URL hoeft helemaal niet per se de file-name aan te geven. Dat maak jij d'r nu gezellig van omdat jou dat nu mooi uitkomt. Maar in werkelijkheid zegt 't hooguit iets over de vindplaats van een bepaalde resource.

Inderdaad, maar niets mis mee toch? Steve Jobs heeft door te miereneuken een bedrijf van bijna-failissement tot de (op een na) rijkste van de wereld gemaakt. En inderdaad, als ik er niets aan had was ik er niet uit liefdadigheid over begonnen ofzo.

[NMe]

Sando schreef op vrijdag 26 augustus 2011 @ 07:46:
[...]

Anyway, gewoon even ter point-of-view, het url geeft de resource van een location. De resource is dus full.jpg. Als je een truukje nodig hebt om de resource te hernoemen, dan is dat gewoon een duct-tape oplossing. En dat is imo gewoon niet netjes.

Duct tape is heel populair, wordt heel veel gebruikt. Maar noem het geen chirurgisch staal.

Als je niet kan devven is dat helemaal niet erg hoor, maar ga dan niet een professionele developer afvallen voor het correct toepassen van een HTTP-header op een bestand dat via een script aangeboden wordt. Dit is gewoon de gangbare manier om dit soort dingen aan te pakken. Daar is geen ducttape aan te pas gekomen. Dat jij vervolgens gekke dingen probeert te doen die nooit voorzien zijn bij het maken van de site is jouw probleem. Ik durf zelfs te zeggen dat jij een ducttapeoplossing hebt als je met wget spul binnen gaat lopen trekken.

[Osiris]

Sando schreef op vrijdag 26 augustus 2011 @ 17:43:
[...]

Wat weer een typische tweaker-reactie. Doe eens niet mij persoonlijk aan te vallen. Ik heb geen shell geprogrammeerd. -e is een populaire persoonlijke draai van iemand anders die niet officiëel in sh zit.

echo is een language construct, en veel compacte versies van linux hebben geen /bin/echo.

't Is geen persoonlijke aanval, jammer dat je dat zo ziet. Bedoelde 't meer algemeen.

En hoezo is 'echo een language construct'? We hebben het hier over een frikkin' OS wat samen aan elkaar gebonden zit door wat libjes en wat programmaatjes. We hebben het hier niet over een programmeertaal ofzo. Iig, mijn punt was dat je NIET zomaar als argument kunt gebruiken dat `-e` toevallig in `sh` geen officiele flag is. Dat zegt simpelweg geen klap. Uiteindelijk is 't alsnog `wget` die een bepaalde keus maakt en die keus kun je beïnvloeden en of `-e` nou wel of geen officiele flag in sh is, maar wel in bash en in de losstaande /bin/echo, care.

Wat Erkens (en ik erboven) aangeven is wél een argument. Er staat niets over 'filename' in de URL-specs e.d..

[ Voor 5% gewijzigd door Osiris op 26-08-2011 18:09 ]

[Erkens]

Sando schreef op vrijdag 26 augustus 2011 @ 17:43:
echo is een language construct, en veel compacte versies van linux hebben geen /bin/echo.

Als we toch mieren willen gaan voortplanten... wat je hier beweerd is ook niet geheel waar. Dergelijke compacte versies hebben gebruiken bijvoorbeeld busybox, en dan heb je een symlink van /bin/echo naar de busybox executable

Zelfde geld eigenlijk ook voor die bestandsnamen in de URL, het is er wel, en het werkt allemaal, maar het is niet precies zoals jij het verwacht

[Sando]

NMe schreef op vrijdag 26 augustus 2011 @ 17:53:
[...]
Dat jij vervolgens gekke dingen probeert te doen die nooit voorzien zijn bij het maken van de site is jouw probleem. Ik durf zelfs te zeggen dat jij een ducttapeoplossing hebt als je met wget spul binnen gaat lopen trekken.

Ik was allang tevreden bij

Erkens schreef op donderdag 25 augustus 2011 @ 09:45:
[...]
als je de optie --content-disposition gebruikt voor wget, dan werkt het wel.

Ik durf zelfs te zeggen dat jij een ducttapeoplossing hebt als je met wget spul binnen gaat lopen trekken.

ben ik ook wel met je eens.

Osiris schreef op vrijdag 26 augustus 2011 @ 18:08:
[...]
Iig, mijn punt was dat je NIET zomaar als argument kunt gebruiken dat `-e` toevallig in `sh` geen officiele flag is.

Dat klopt ook wel, maar ik probeerde een vergelijking te maken in het niet gangbaar zijn van bepaalde truukjes die we vroeger ook niet nodig hadden.

Ik vond het gewoon een rare gang van zaken. Volgens sommigen ben ik zelf een rare gang van zaken, maar feit is dat ik deze gangbare manier nog niet eerder heb opgemerkt, terwijl ik altijd leuke plaatjes e.d. 1-click-opsla, vroeger met een firefox plugin en nu met een wget duct-tape oplossing, en het alleen bij tweakers altijd gemakzuchtig gezien niet werkte.

-edit-

Maar zoals Erkens ook zegt, mijjn kennis is outdated en niet geheel waar.

[ Voor 3% gewijzigd door Sando op 27-08-2011 03:36 ]

[Sando]

Erkens schreef op donderdag 25 augustus 2011 @ 09:45:
[...]

als je de optie --content-disposition gebruikt voor wget, dan werkt het wel.

Ik wil niet stoken, maareh

quote: man wget

‘--content-disposition’
If this is set to on, experimental (not fully-functional) support for Content-Disposition headers is enabled. This can currently result in extra round-trips to the server for a HEAD request, and is known to suffer from a few bugs, which is why it is not currently enabled by default.

Als een standaardtool als wget al wat op te merken heeft, dan zou ik toch liever de content-disposition header links laten liggen.

Er zijn veel topics te vinden waar mensen klagen dat wget die optie default moet zetten, maar de GNU devs zeggen in feite dat content-disposition een duct-tape oplossing is die men beter niet moet gebruiken.

Anyway, wie weet een truukje in python om de nieuwe filename op te vangen?

Voorbeeld:
wget plaatje
move plaatje /grappige/plaatjes
#move plaatje('s content disposition) /grappige/plaatjes

[Xander]

Als wget een standaard uit 1997 niet goed geïmplementeerd krijgt vraag ik me eerder af of wget niet met duct-tape in elkaar zit.

Maare, hoezo zoek je nu een truukje? Met die wget-optie zou het toch gewoon moeten werken?

[Femme]

Sando schreef op donderdag 25 augustus 2011 @ 00:13:

Volgens mij was het netter om ipv
x6FgiXzjy1cXaNvkqGTDsuPa/full.jpg
links te hebben als
full/x6FgiXzjy1cXaNvkqGTDsuPa.jpg
maar dat is waarschijnlijk een gedoe oplossing voor een te klein probleem.

Ik vind dat laatste ook netter. Nog mooier is om de titel van de afbeelding in de url op te nemen.

[Sando]

bump wegens vandaag ervaren irritatie om de zelfde reden

Xander schreef op vrijdag 09 september 2011 @ 16:49:
Maare, hoezo zoek je nu een truukje? Met die wget-optie zou het toch gewoon moeten werken?

De url van alle plaatjes die in een tweakers fotoalbum gehost zijn heten gewoon full.jpg, allemaal. Als ik een scriptje loslaat die weet dat de filename full.jpg is, maar content-disposition (wget) maakt er iets anders van, dan werkt dat scriptje niet meer. Ik moet dus een helderziende functie hebben die bij deze compleet logische tweakers-oplossing kan ruiken wat de filename eigenlijk moet zijn.

Ik weet, ik zet het een beetje flauw neer, maar in mijn vorige berichtje kwam niet goed over wat ik bedoelde.

Het zou natuurlijk lame zijn als ik 50 regels met ge-cURL en regular expression gehannes moet maken om een header uit te lezen die de nieuwe filename in een variabele stopt voor een script van 5 regels, omdat dit volgens een aantal van jullie logischer is dan gewoon de filename in de url te gebruiken. Daarom zoek ik een simpel truukje.

realname = get-content-disposition-name(url)

Verstoan je?

[NMe]

Je begrijpt dat je nu van jouw probleem het probleem van Tweakers aan het maken bent? Dat fotoalbum is nooit bedoeld om scripted leeg te trekken.

[Wiethoofd]

NMe schreef op woensdag 28 september 2011 @ 17:29:
Je begrijpt dat je nu van jouw probleem het probleem van Tweakers aan het maken bent? Dat fotoalbum is nooit bedoeld om scripted leeg te trekken.

* Wiethoofd heeft anders gewoon een 'Backup maken' linkje in z'n fotoalbum admin gedeelte staan. Waarom die bij een onclick direct de download gaat genereren en serveren is mij niet helemaal duidelijk, een conformation bij een >50MB fotoalbum lijkt me wel prettig om onnodige load op de server te voorkomen.

@ Redsandro, cURL met een CURLOPT_HEADER op 1 of true levert je netjes de Content-Disposition op..

PHP:

<?php
$ch = curl_init('http://tweakers.net/ext/f/2Vpiv7vOCDOZ4HX5PUJVfmIH/full.jpg');
 curl_setopt($ch, CURLOPT_HEADER, 1);
 curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

$img = curl_exec($ch);
 curl_close($ch);
print_r($img);
?>

[Sando]

@NMe alweer dat flauwe leegtrekken, je lijkt mace wel. Ik heb het al eerder uitgelegd. Ik begrijp wat ik doe. Ik probeer enerzijds uit te leggen dat Tweakers een probleem heeft gemaakt waar dat niet nodig was, en anderzijds een oplossing te vinden voor wat volgens de helft van de reacties een normale gang van zaken is.

Het nadeel van deze gang van zaken is al besproken, maar wat is het voordeel eigenlijk? Dat wget zelf een sukkel is, is natuurlijk geen argument.

@Wiethoofd Superbedankt, maar goed dat ik het even vroeg want ik zat alweer veel ingewikkelder te klooien. Moet ik alleen wel eerst pycurl installeren.

Ik heb trouwens ook een backup maken linkje die inderdaad mijn hele album zonder verdere vragen 'leegtrekt', maar het gaat mij er dus o.a. om op allerlei sites waaronder Tweakers een occasional grappig plaatje in één klik op te slaan naar mijn hilarische directory en nog een beetje te postprocessen.

Daarbij is tot nu toe Tweakers de enige geweest die problemen geeft door de manier waarop het fotoalbum is opgezet. Wel typisch voor tweakers (de gebruikers) om glashard te beweren dat dit normaal is

offtopic:
ookal zijn ze de uitzondering.

TLDR:
[list]
• Wat is het voordeel van resource location != resource name en headers om dat te corrigeren?[list]• vraag staat nog open
• Hoe kan ik de content-disposition opvragen om hier rekening mee te houden?

• cURL met een CURLOPT_HEADER op 1.

[NMe]

Sando schreef op woensdag 28 september 2011 @ 23:40:
@NMe alweer dat flauwe leegtrekken, je lijkt mace wel. Ik heb het al eerder uitgelegd.

Nee, het gaat erom dat jij zo'n beetje de enige bent die er echt problemen mee heeft dat die images allemaal dezelfde naam hebben. Wat denk je dat het devteam eerder oppakt, iets waar alleen jij baat bij hebt of iets waar de hele community wat aan heeft?

Het nadeel van deze gang van zaken is al besproken, maar wat is het voordeel eigenlijk? Dat wget zelf een sukkel is, is natuurlijk geen argument.

Het voordeel is dat er geen tijd verspild wordt aan het wijzigen van iets om iets mogelijk te maken dat nooit bedoeld gebruik van de feature is geweest.

[Sando]

NMe schreef op woensdag 28 september 2011 @ 23:47:
[...]
Nee, het gaat erom dat jij zo'n beetje de enige bent die er echt problemen mee heeft dat die images allemaal dezelfde naam hebben.

Nouja, als het daarom ging kon je dat gewoon zeggen. 'Leegtrekken' heeft zo'n negatieve bijklank. Vaak geassocieerd met misbruik en het stelen van bandbreedte. Mijn punt op deze manier een valse negatieve klank geven is geen nette argumentatie tegen mijn feedback.

Wat denk je dat het devteam eerder oppakt, iets waar alleen jij baat bij hebt of iets waar de hele community wat aan heeft?

Retorische vraag is retorisch.

Maar de community heeft geen voordeel aan de huidige opzet met identieke bestandsnamen. Dan kan je beter stellen: Iets waar alleen jij baat bij hebt of iets waar niemand wat aan heeft?'
Dan nog heb je gelijk, je gaat niet voor 1 persoon iets fixen. Maar het was een andere zaak als met mij vele tweakers hier om welke reden dan ook last van hadden. Daarom oorspronkelijk dit topic.

Enkelen zijn het wel met me eens. Sterker nog, niemand heeft gezegd het met me oneens te zijn. Maar niemand heeft er last van, en daarom heb je gelijk.

Het voordeel is dat er geen tijd verspild wordt aan het wijzigen van iets om iets mogelijk te maken dat nooit bedoeld gebruik van de feature is geweest.

Ah kijk, dat is een verkapte 'niemand heeft er wat aan, maar we hebben in het begin een ontwerp gekozen waarbij geen rekening is gehouden met dergelijke toepassingen.'
Zeg dat dan.

Of mijn persoonlijke favoriet: 'Niemand heeft er wat aan en er is geen mens die statische resources zo inzet, maar we zijn ook tweakers dus tijdens het ontwerp kozen we voor een omslachtige methode "omdat het kan" en ons hip leek.'

Ik heb mijn oplossing al, ben blij, en ik ben natuurlijk een beetje irritant met mijn gemierenn(n)neuk. Geef ik toe. Sorry. Maar ik wordt een beetje irritant als het 22 posts aan bal kaatsen moet duren voordat de aap uit de mouw komt: Het is een designfout.

Althans, fout, dat is discutabel en dat blijkt, maar omdat ik met een nadeel kom en na 26 posts nog geen voordeel heb gehoord houd ik onder de streep op mijn kladblokje een negatief saldo aan voordelen over.

[rob_erwt]

Sando schreef op donderdag 29 september 2011 @ 02:24:
Ik heb mijn oplossing al, ben blij [...]

Mooi, dan kan deze dicht

Om toch nog iets constructiefs toe te voegen: in het algemeen zien we wel wat in backupfunctionaliteit rechtstreeks in het fotoalbum. Dat zullen we dan ook op de backlog zetten, maar verwacht niet dat het hele hoge prioriteit krijgt.