Probleem! Maximaal aantal tekens?

[Anoniem: 144949]

Weet niet juist of dit hier moet of bij bugs, maar plaats het hier mits het niet echt een bug is denk ik.

Het betreft dit topic: Welke voeding heb ik nodig? Deel 13
Ik wil nog enkele aanvullingen aanbrengen in de topicstart, maar dan krijg ik de volgende boodschap:

Er is iets fout gegaan. Probeer het later nog eens, of ga terug.

De inhoud is te lang na conversie: 65,662 bytes na conversie, 127 bytes meer dan mogelijk.
(interne identificatie: message::update::maxcolumnsize_exceeded)

Betekent dit dat het maximaal mogelijke aantal karakters in 1 post zijn overschreden? Of is het probleem iets anders? Kan ik dit verhelpen en alsnog de aanvullingen erbij zetten? Zo nee, is er dan een mogelijkheid dat ik nog een post kan doen tussen de topicstart, en de posts die daaronder komen waarin ik dan 'het vervolg' kan zetten? Dus 2 posts vlak onder mekaar zodat ik de topic start daarover kan verdelen.

Graag raad

[pven]

Die foutmelding lijkt mij toch duidelijk?

[Remy]

Graag raad

Probeer wat efficiënter met je tekst om te gaan in die TS: gooi er dus wat woorden uit Door even een paar zinnen die in 1 zin gevat kunnen worden, te schrappen heb je alweer een aantal bytes vrij

[leuk_he]

Sommige grote topic starts gaan ook over 2 messages heen (kijk maar eens in sgd). SOms wordt daar ook vast een 2e message gereserveerd.

/edit: en ik zie dat de 2e message ook van jou is. Was let je hier in door te gaan? scheel!

[ Voor 31% gewijzigd door leuk_he op 09-09-2005 12:30 ]

[Anoniem: 26306]

In feite heeft de topicstart al niets meer met een topic te maken, en zou de informatie opgenomen moeten worden in een of ander kennissysteem. Bijvoorbeeld in een Wiki.

[Remy]

leuk_he: de tweede message is van Eldee, dus daar kan hij moeilijk in doorgaan

[leuk_he]

Anoniem: 26306 schreef op vrijdag 09 september 2005 @ 12:29:
In feite heeft de topicstart al niets meer met een topic te maken, en zou de informatie opgenomen moeten worden in een of ander kennissysteem. Bijvoorbeeld in een Wiki.

Dat heb ik met het grote emule topic ook gedaan. Gotwiki weet je wel. (opgezet voor SA, maar wat let je? )

http://gotwiki.spider007.net/GoTwiki/Emule

[Anoniem: 144949]

Voorlopig opgelost door zuiniger te zijn met woorden. Heb wat kunnen weglaten en daarmee een review kunnen toevoegen. Probleem is dat er waarschijnlijk nog wel een pak toevoegingen gaan komen, en dat dat er allemaal niet gaat in geraken door enkel zuinig te zijn op woorden.
Dus in het vervolg al zeker 2 posts reserveren voor de topic start.
Maar er is geen mogelijkheid om nu nog een post 'ertussen te wringen' voor dit deel?

[Remy]

Maar er is geen mogelijkheid om nu nog een post 'ertussen te wringen' voor dit deel?

Dat zal vast mogelijk zijn, maar dan moet er waarschijnlijk in de db gerotzooid worden en de situatie is niet zo nijpend dat dat nodig is

Dus in het vervolg al zeker 2 posts reserveren voor de topic start.

Yup

[Anoniem: 26306]

Het idee van HTTP en HTML draait een beetje om het begrip "HyperText". Maak daar nou gewoon gebruik van. Niet elke keer verdergaan in een nieuw topic met weer de hele tekst plus een aanvulling, maar op één centrale plaats de kennis vergaren. Daar kun je in een topicstart dan naar (hyper)linken, om in het topic te discussiëren, vragen te stellen of beantwoorden, of suggesties te kunnen doen.

Dus ik zeg het nog maar een keer: eigenlijk hoort dat soort informatie niet in een topicstart. Dat het wel gebeurt, is omdat er geen beter alternatief is. Spider.007 is voor SA begonnen aan een Wiki, een prima initiatief. Maar het zou mooi zijn als er uiteindelijk een centraal systeem komt, waarin men ook nog eens kan zoeken (in topics binnen het forum, in knowledge base pagina's of artikelen op de t.net frontpage. Dat is nu nog even toekomstmuziek.

Maar het probleem is niet het aantal tekens. Het probleem is dat een forum niet geschikt is voor dit soort dingen.

[moto-moi]

Remy schreef op vrijdag 09 september 2005 @ 12:44:
Dat zal vast mogelijk zijn, maar dan moet er waarschijnlijk in de db gerotzooid worden en de situatie is niet zo nijpend dat dat nodig is

Neuh, de term is: 'creatief mergen'
Je moet dus een posting van de topicstarter hebben die zwaar voor de topicstartdatum ligt.
Daar merge je de rest aan vast, en dan heb je dus een extra posting in dat topic.
Probleem daarmee is dat alle verwijzingen naar het originele topic verkloot zijn, dus mensten die het gebookmarkt hebben , of erin gepost hebben kunnen het topic niet terugvinden.
Ik dacht dat het e.e.a. daarvoor wel gefixed was in 1.9.4, maar dat zouden we ff moeten testen op beta

[PierreAronnax]

moto-moi schreef op vrijdag 09 september 2005 @ 12:48:
Neuh, de term is: 'creatief mergen'
Je moet dus een posting van de topicstarter hebben die zwaar voor de topicstartdatum ligt.
Daar merge je de rest aan vast, en dan heb je dus een extra posting in dat topic.

In plaats van een merge kan je toch ook een move van een enkel bericht doen? Als dit bericht ouder is dan het onderwerp komt dit bericht automatisch bovenaan te staan, en dan lijkt me dat de bookmarks dan wel heel blijven. (het topicnummer veranderd niet).
Of je moet zelfs geluk hebben en een bericht van de TS tussen woensdag 07 september 2005 13:04 en donderdag 08 september 2005 04:13 hebben

[Anoniem: 144949]

PierreAronnax schreef op vrijdag 09 september 2005 @ 13:10:
Of je moet zelfs geluk hebben en een bericht van de TS tussen woensdag 07 september 2005 13:04 en donderdag 08 september 2005 04:13 hebben

Ben niet mee met dat mergen, bedoel je dan een bericht van mij tussen die tijdsspanne? Waarschijnlijk zal er wel een zijn hoor.

Verder een link maken naar een 'wiki' of wat het ook mogen zijn, waar er meer plek is, ben ik persoonlijk niet zo'n voorstander voor, gewoon omdat je dan weer moet gaan linken. Ik vind het veel netter dat alles gecentraliseerd is in 1 topic...

Beste oplossing lijkt mij tot nu gewoon 2 posts reserveren, maarja voor dit deel is het dan wel al te laat, is wel spijtig...

[JHS]

Beste oplossing zou zijn als de inhoud van de wiki / centrale opslag plaats ook te zien zou zijn zou zijn, of een samenvatting ervan, in de TS. Maar wordt wat moeilijk en ingewikkeld .

[sPENKMAN]

Ik denk dat je vast wel een plekje geregeld kan krijgen op de GoT Wiki, hoe de status exact is op dit moment weet ik niet. De test ging in eerste instantie over Software Algemeen gerelateerde problemen maar er mochten ook andere categorieën gebruikt worden.

De GoT wiki: http://gotwiki.spider007.net/GoTwiki/Hoofdpagina
Het topic: GoTwiki - vragen en feedback

toevoeging:
Een aantal zaken zou je daar neer kunnen zetten in de uitgebreide versie waarnaar je linked in het topic

[ Voor 15% gewijzigd door sPENKMAN op 09-09-2005 15:17 . Reden: typo\toevoeging ]

[.oisyn]

[user-mode]
Belachelijk dat die limit er eigenlijk is, of dat ie iig zo kort is. Die extra byte of 2 per post om die limiet te verhogen maakt natuurlijk ook geen zak uit.

[Anoniem: 144949]

Gebeurd het eigenlijk vaak dat men aan de limiet komt? Want als het niet veel uitmaakt, kunnen ze die toch gewoon afschaffen?

[PierreAronnax]

.oisyn schreef op vrijdag 09 september 2005 @ 15:47:
[user-mode]
Belachelijk dat die limit er eigenlijk is, of dat ie iig zo kort is. Die extra byte of 2 per post om die limiet te verhogen maakt natuurlijk ook geen zak uit.

In een text veld van MySQL past maximaal 64K (= 65536 byte). De TS komt daar met zijn 65662 dus 126 byte bovenuit.

De volgende stap (mediumtext) zou 16MB worden, en dat lijkt me teveel van het goede

[chem]

Anoniem: 144949 schreef op vrijdag 09 september 2005 @ 15:48:
Gebeurd het eigenlijk vaak dat men aan de limiet komt? Want als het niet veel uitmaakt, kunnen ze die toch gewoon afschaffen?

Het is zover ik weet de 3e keer in een paar jaar dat dit is voorgekomen afaik.

Cheatah heeft wel een punt; dit is veel te veel informatie voor een forum. Het is ook een discussie-forum en geen knowledge base

Wat de beste oplossing is weet ik niet, ik weet ook niet in hoeverre dit binnen React's domein moet gaan vallen en in hoe verre je naar een KB of Wiki moet gaan kijken.

De oplossingen die mogelijk zijn, zijn vrij kazig; handmatig berichten dmv de DB of de topicadmin ertussen frommelen en dat soort zaken. De kolomgrens van 64kb oprekken naar de volgende stap (8 megabyte) is niet echt een oplossing, het probleem is niet de 64kb-grens maar de vraag wat meer dan 64kb nou echt toevoegt.

[.oisyn]

PierreAronnax schreef op vrijdag 09 september 2005 @ 15:58:
[...]


In een text veld van MySQL past maximaal 64K (= 65536 byte). De TS komt daar met zijn 65662 dus 126 byte bovenuit.

De volgende stap (mediumtext) zou 16MB worden, en dat lijkt me teveel van het goede

Zoals ik al zei, belachelijk dat die limiet er is. Waarom is een limiet van 16mb teveel van het goede? Alsof iedereen dan ineens 16 mb posts gaat zitten maken. Net alsof nu iedereen 64k posts zit te maken . Die limiet van 64k vind ik te weinig, daar kom je nogal eens aan zoals nu ook weer blijkt. Wmb haal je die hele limiet weg, maar dat heeft weer andere implicaties (er is hoe dan ook een limiet, dus die kun je beter vaststellen). 16 MB lijkt me een prima oplossing.

Daarnaast weerhoudt je er niets van om een mediumtext veld in de db te limiteren naar minder dan 16 mb, mind you.

[ Voor 22% gewijzigd door .oisyn op 09-09-2005 16:02 ]

[leuk_he]

Oprekken is mooi (je komt er vlotter aan dan je denkt hoor). Nog mooier is eens de grote topics eens goed op de pijnbank te leggen. (subtreads), beter doorzoekbaar. automatische bookmakrs als er over de (kunstmatige) grens van 1000 post wordt gegaan.

En voor de topic starts van dergelijke topic is een of andere inline frame (of een soort van include) van een extra groot veld wel handig. Helpt ook weer als je van de een naar de andere gorote topic over stapt. Ik zal eens een keer een grote feature request maken voor groto topics. (alsof de devvers helemaal niks te doen hebben )

[.oisyn]

chem schreef op vrijdag 09 september 2005 @ 16:01:
De oplossingen die mogelijk zijn, zijn vrij kazig; handmatig berichten dmv de DB of de topicadmin ertussen frommelen en dat soort zaken. De kolomgrens van 64kb oprekken naar de volgende stap (8 megabyte) is niet echt een oplossing, het probleem is niet de 64kb-grens maar de vraag wat meer dan 64kb nou echt toevoegt.

Volgens die redenatie kun je nu dus ook een 256 byte limiet invoeren, of een 4k limiet. Er zijn maar weinig posts die over die 4k heen gaan. Maar dat neemt niet weg dat je af en toe wel meer wilt dan 4k, net zoals je af en toe ook meer wilt dan 64k. 16 mb (waarom 8mb? dat zijn maar 7 bits extra in het lengte-veld) "should be enough for everyone"

[Anoniem: 144949]

Oeps hevige discussie uitgelokt...

Waarom ik graag alles wel in de Topicstart wil zonder externe linkjes: omdat de meeste forumleden dan sneller geneigd zijn om de topicstart door te nemen en te kijken of hun vraag erin beantwoord wordt ipv ze zomaar te posten terwijl ze al beantwoord wordt in de topic start. Als je daarvoor eerst moet gaan zitten klikken op linkjes, gaan ze al eerder geneigd zijn om 'foert' te zeggen en gewoon te posten.
Dus als alles goed en duidelijk en direct toegankelijk om te lezen in de topic start staat, gaan er minder 'slechte' vragen voorkomen in het topic, en dit kan het topic allen ten goede komen.

Het is immers toch zo dat de mods zoveel mogelijk proberen te voorkomen dat er vragen worden gesteld die iedereen makkelijk zelf kan vinden, niet???

Het was idd dom van mij om geen 2 posts te reserveren, maar is de eerste keer dat ik de topicstart heb verzorgd van dit forum...

[Anoniem: 26306]

Anoniem: 144949 schreef op vrijdag 09 september 2005 @ 19:27:
Oeps hevige discussie uitgelokt...

Waarom ik graag alles wel in de Topicstart wil zonder externe linkjes: omdat de meeste forumleden dan sneller geneigd zijn om de topicstart door te nemen en te kijken of hun vraag erin beantwoord wordt ipv ze zomaar te posten terwijl ze al beantwoord wordt in de topic start. Als je daarvoor eerst moet gaan zitten klikken op linkjes, gaan ze al eerder geneigd zijn om 'foert' te zeggen en gewoon te posten.
Dus als alles goed en duidelijk en direct toegankelijk om te lezen in de topic start staat, gaan er minder 'slechte' vragen voorkomen in het topic, en dit kan het topic allen ten goede komen.

Als je over toegankelijkheid gaat beginnen, moet ik je teleurstellen. Je topicstart is niet gemaakt met het ook op toegankelijkheid. Bepaalde opmaakcode is totaal verkeerd gebruikt. Er wordt vanalles bijgehaald terwijl het eigenlijk aparte onderwerpen zijn, etcetera.

Ik vraag me af waar je het vandaan haalt dat mensen niet op linkjes willen klikken, maar verder zijn er gewoon moderators om te zorgen dat het forum niet in een vragendumpplaats verandert. Bovendien hoeven het helemaal geen externe linkjes zijn, maar zouden het gewoon linkjes kunnen zijn naar pagina's op tweakers.net, in de huisstijl van tweakers.net. Ben je meteen van die walgelijke kleurcombinatie af

Het is immers toch zo dat de mods zoveel mogelijk proberen te voorkomen dat er vragen worden gesteld die iedereen makkelijk zelf kan vinden, niet???

Juist daarom moet de informatie op een goede manier worden aangeboden.

Het was idd dom van mij om geen 2 posts te reserveren, maar is de eerste keer dat ik de topicstart heb verzorgd van dit forum...

Het is helemaal niet dom, want zoals ik al zei: het slaat nergens op om zoiets in een topic te zetten.

[djluc]

Wat mooi zou zijn:
Een centrale knowledge base van Tweakers.net waar iedereen een contribute kan doen die lid is. Denk bijvoorbeeld aan een wiki maar dan geheel in tweakers stijl. Vervolgens zou je dan, net zoals een Iframe o.i.d., bepaalde content in de topicstart plaatsen. Het mooiste zou het natuurlijk zijn als je dat doet middels een tag. Denk aan iets als:

[import=3323232]form factors![/import]
[import=7832732]VoedingsFAQ[/import]

Dan bouw je een mooie knowledge base op en is iedereen snel op de hoogte van de informatie omdat dit bovenaan de juiste topics staat. Technisch gezien moet dit ook te doen zijn, alleen caching schijnt nogal een heikel punt te zijn. Dat zou hier eventueel tegen kunnen zitten omdat de content kan veranderen.

[Anoniem: 144949]

Anoniem: 26306 schreef op vrijdag 09 september 2005 @ 20:04:
Als je over toegankelijkheid gaat beginnen, moet ik je teleurstellen. Je topicstart is niet gemaakt met het ook op toegankelijkheid. Bepaalde opmaakcode is totaal verkeerd gebruikt. Er wordt vanalles bijgehaald terwijl het eigenlijk aparte onderwerpen zijn, etcetera.

Ok, wat kan ik er dan concreet aan verbeteren? Het is zo dat ik de topic start heb gebaseerd op de topic starts van de vorige delen. Heb het design en opmaak overgenomen en zaken toegevoegd. Over het gebruik van codes: heb gewoon gekeken tot het resultaat het gewenste resultaat was.
Warom het zo uitgebreid is en er vanalles wordt bijgehaald: omdat het topic anders toch wordt opgevuld met vragen die constant opnieuw en opnieuw en opnieuw gesteld worden...

Ik vraag me af waar je het vandaan haalt dat mensen niet op linkjes willen klikken,

ikzelf irriteer me er regelmatig aan, mar hangt af van topic tot topic, in de ene is het al beter georganiseerd dan in de andere

Wat ik eventueel wel een mooie optie zou vinden: momenteel staat elk stukje tekst in een kadertje met een titel
Als ik nu in de topicstart gewoon alle titeltjes kan zetten die dan aanklikbaar zijn, waardoor je naar het stukje tekst gaat dat erachter zit. en dit stukje tekst is dan in de stijl en lay-out van een gewone post op GOT...
Dit zou netjes zijn! Kan ik dit realiseren?

[MSalters]

De 5-regels-code-oplossing: als een post over de 64K heengaat splits je'm automatisch in twee posts. De tweede komt dan direct onder de eerste met de extra karakters. Met 10 regels code kun je't zelfs netjes afbreken.

[NMe]

Dan zou ik toch liever gaan voor de 0-regels-code-oplossing van .oisyn.

Die limiet is stom: zolang een algemene KB en/of Wiki nog niet gerealiseerd is, kan het nou eenmaal wel eens voorkomen dat iemand wat grotere posts wil maken, vooral in een topicstart. Waarom zou je mensen daarin gaan limiteren?

[crisp]

MSalters schreef op vrijdag 09 september 2005 @ 23:43:
De 5-regels-code-oplossing: als een post over de 64K heengaat splits je'm automatisch in twee posts. De tweede komt dan direct onder de eerste met de extra karakters. Met 10 regels code kun je't zelfs netjes afbreken.

De beste stuurlui... of weet jij hoe de React code eruit ziet en heb je het lokaal al werkend? In dat geval zou ik zeggen: stuur maar door die code naar Parse

-NMe- schreef op zaterdag 10 september 2005 @ 00:09:
Dan zou ik toch liever gaan voor de 0-regels-code-oplossing van .oisyn.

Die limiet is stom: zolang een algemene KB en/of Wiki nog niet gerealiseerd is, kan het nou eenmaal wel eens voorkomen dat iemand wat grotere posts wil maken, vooral in een topicstart. Waarom zou je mensen daarin gaan limiteren?

Ik weet niet wat de consequenties zijn van het omzetten van het veld naar MEDIUMTEXT vwb performance en opslag capaciteit...

[Paul]

Je zit hier dus eigenlijk niet met een databaseprobleem, maar met een (reeel of verzonnen, dat zou ik zo niet weten, laten we het voor het gemak op reeel houden) mentaliteitsprobleem. Je kunt namelijk gewoon naar 1 of meer topicstarts van vorige delen linken, en als er anchors in die topicstarts staan kun je zelfs naar punten binnen die topicstart springen.
Enige probleem is dan dus dat je verwacht dat users niet de moeite nemen om naar dat andere topic te springen, en dat terwijl juist de info in dat topic (zo goed als) niet verouderd, waardoor niet willen hyperklikken pure luiheid is.

Je kunt dan dus wel een 2e of zelfs 3e post gaan reserveren, maar wat je eigenlijk wilt is dat mensen ipv hun vraag te dumpen de search gebruiken en linkjes in de TS te volgen (de aanname dat men de TS leest heb je al gedaan), en dan komen we weer op het aloude vraagstuk m.b.t. megatopics. Een hogere limiet is (imho) dus gewoon symptoombestrijding van een ouder probleem.

[NMe]

@crisp: wat betreft storage requirement, uit de manual:

quote: http://dev.mysql.com/doc/mysql/en/storage-requirements.html

MEDIUMBLOB, MEDIUMTEXT L+3 bytes, where L < 2²⁴

Dit betekent dat berichten welgeteld één byte meer ruimte in beslag gaan nemen, omdat TEXT L+2 bytes nodig heeft. Wat betreft performance...tsja, daar vind ik niet veel over. Ik verwacht echter dat je alleen in de search echt last zou kunnen hebben van echt performace verlies, en dat het op de rest van het forum wel mee zou vallen eigenlijk. Maar ik heb niet zoveel verstand van dit soort dingen als bijvoorbeeld ACM, dus pin me er niet op vast.

@Paul Nieuwkamp: je hebt gelijk dat het eigenlijke probleem is dat mensen lui zijn. Dan is de logische wedervraag natuurlijk: wat doe je eraan? Je kan mensen wel gaan verplichten geen info meer op te nemen in hun topicstart, maar dat maakt het beleid weer lekker doorzichtig: "Geef altijd zoveel mogelijk info in je TS, behalve als je een groot topic opent." Lijkt me niet handig.

Een ander ding waar grotere message sizes handig voor kunnen zijn, is voor FAQ's. In P&W ben ik geen FAQ tegengekomen waar dit het geval is, maar ik heb een paar FAQ's rond zien zwerven op het forum die verspreid moesten worden over meerdere berichten, terwijl dat ook in één bericht had gekund bij een ander datatype.

[Paul]

-NMe- schreef op zaterdag 10 september 2005 @ 01:57:
"Geef altijd zoveel mogelijk info in je TS, behalve als je een groot topic opent." Lijkt me niet handig.

"Zo veel mogelijk info" hoeft toch niet letterlijk in dat tekstvak voor je neus geplakt te worden? Zeker bij grote topics met veel statische content kun je dat perfect met linkjes naar andere topics doen Als je dat een beetje goed anchort en groepeert dan krijg je hetzelfde idee als de huidige FAQ's en je hoeft op de eerste pagina / bij een quicksearch niet je scrollwiel aan gort te draaien totdat je voorbij de startpost bent

[Anoniem: 144949]

Anoniem: 144949 schreef op vrijdag 09 september 2005 @ 23:41:
Wat ik eventueel wel een mooie optie zou vinden: momenteel staat elk stukje tekst in een kadertje met een titel
Als ik nu in de topicstart gewoon alle titeltjes kan zetten die dan aanklikbaar zijn, waardoor je naar het stukje tekst gaat dat erachter zit. en dit stukje tekst is dan in de stijl en lay-out van een gewone post op GOT...
Dit zou netjes zijn! Kan ik dit realiseren?

Ik weet dus niet of dit mogelijk is en hoe ik er dan concreet aan moet beginnen (ben niet echt een code-kenner). Alle titeltjes zouden toch zeker in de topic start zichtbaar moeten zijn zodat de mensen direct kunnen zien waarover er dan toch info te vinden is.

[Erkens]

Paul Nieuwkamp schreef op zaterdag 10 september 2005 @ 04:03:
[...]

"Zo veel mogelijk info" hoeft toch niet letterlijk in dat tekstvak voor je neus geplakt te worden? Zeker bij grote topics met veel statische content kun je dat perfect met linkjes naar andere topics doen Als je dat een beetje goed anchort en groepeert dan krijg je hetzelfde idee als de huidige FAQ's en je hoeft op de eerste pagina / bij een quicksearch niet je scrollwiel aan gort te draaien totdat je voorbij de startpost bent

Je vergeet alleen dat je vervolgens die oude topicstarts niet meer kan editen als er bijvoorbeeld een foutje in zit ofzo, dan moet je dat altijd via een modje doen.
Het zou dus idd veel handiger zijn om al die informatie (ook) in die wiki zetten, en dan daar naartoe linken, en het forum (die grote topics) gebruiken waar het voor is: de discussie er omheen

[NMe]

...maar momenteel is er nog geen forumbreed Wiki, dus tot die tijd...?

[Erkens]

-NMe- schreef op zaterdag 10 september 2005 @ 22:49:
...maar momenteel is er nog geen forumbreed Wiki, dus tot die tijd...?

dan is mijn vraag: waarom niet

[ACM]

Erkens schreef op zaterdag 10 september 2005 @ 22:52:
dan is mijn vraag: waarom niet

Omdat we aan het uitzoeken zijn hoe we een single-logon met de FP of het forum kunnen realiseren, zonder zelf gelijk maar een heel (stuk van een) Wiki te herschrijven... En het heeft bij de mensen die ermee bezig zijn niet echt enorme prioriteit.

[Erkens]

ACM schreef op zaterdag 10 september 2005 @ 23:09:
Omdat we aan het uitzoeken zijn hoe we een single-logon met de FP of het forum kunnen realiseren, zonder zelf gelijk maar een heel (stuk van een) Wiki te herschrijven...

duidelijk, was even vergeten dat er natuurlijk ook ingelogt moest worden daarvoor

[Anoniem: 26306]

ACM schreef op zaterdag 10 september 2005 @ 23:09:

Omdat we aan het uitzoeken zijn hoe we een single-logon met de FP of het forum kunnen realiseren, zonder zelf gelijk maar een heel (stuk van een) Wiki te herschrijven... En het heeft bij de mensen die ermee bezig zijn niet echt enorme prioriteit.

Toevallig heb ik zelf flink lopen knoeien met MediaWiki, en daarvan kan ik wel melden dat het goed te "skinnen" is, maar dat ik geen flauw idee heb van hoe goed het met de bestaande/komende GoT/FP accounts te koppelen is.
FYI: ik heb zelf een kleine testomgeving met een op de GoT layout gebaseerde skin, waarin ik de FAQ's en voorwaarden heb geplakt, bij wijze van test.

Het lijkt me duidelijk dat ik er best over wil meedenken als jullie er aan toe gaan komen, maar op dit moment heb ik geen idee van de structuur van de database tabellen zoals deze na de merge gaat worden. Ook weet ik niet of bijvoorbeeld Omega iets kan op dat gebied, zoals zoeken in een forum, frontpage posts en in de wiki?

Maar voor ik er zelf nog veel meer tijd aan besteed (niet dat ik dat zo vreselijk vind), is het een reële optie om MediaWiki (of soortgelijke software) te gebruiken? Of is het waarschijnlijker dat er iets anders (maatwerk) ontwikkeld gaat worden? Zijn er al concrete plannen? Hebben jullie zelf al dergelijk onderzoek gedaan? Heeft het zin als ik uitzoek of het te doen is (en of het is toegestaan) om MediaWiki zo aan te passen dat hij de gebruikers en/of rechten uit een andere database kan halen? Etc?

[ACM]

MSalters schreef op vrijdag 09 september 2005 @ 23:43:
Met 10 regels code kun je't zelfs netjes afbreken.

Splitst ie dan ook netjes de tags op zodat ie ze allemaal aan het eind van het eerste bericht sluit en bij de tweede weer opent? En doet ie dat dan netjes binnen de karakter-limiet?
En is het dan nog steeds 10 regels code? Lijkt me niet.

.oisyn schreef op vrijdag 09 september 2005 @ 16:02:
Waarom is een limiet van 16mb teveel van het goede? Alsof iedereen dan ineens 16 mb posts gaat zitten maken.

De 64K limiet zal inderdaad wel vooral uit praktisch oogpunt gekozen zijn. Desalniettemin vind ik het niet vreemd dat er een limiet is, vooral om te voorkomen dat er gigantische lappen tekst geschreven worden.
Want die lappen tekst moet je toch echt structureren, want er zijn maar heel weinig mensen die ze compleet lezen. En dan heb je dus hyperlinks nodig om in je structuur te navigeren en is het toch relatief weinig moeite om dan twee ipv een posting te gebruiken voor je structuur, de hyperlinks doen het ook prima 'inter post'.

Wmb haal je die hele limiet weg, maar dat heeft weer andere implicaties (er is hoe dan ook een limiet, dus die kun je beter vaststellen). 16 MB lijkt me een prima oplossing.

Er blijft hoedanook een limiet. Onder andere omdat het parsen van de rml nu al op kan lopen tot enkele seconden, het ervoor zorgt dat topics niet ongebreideld groeien, en meer van dat soort redenen.
De langste topics (je weet wel, die in DC en HC crewfora) nu zijn vziw nog altijd geen 16MB in totaal, dus een dergelijke hoeveelheid tekst toelaten voor een enkele reactie vind ik veel te veel. Heb je wel eens een stuk tekst van 1MB in je browserscherm bekeken? Daar is niet tegenaan te scrollen zo veel is het.
Voor jou en andere mensen ter referentie: een pagina van bijna 1MB aan html. En dan voor de gein ook nog enkele RFC-pagina's van tientallen KB's: 51KB, 68KB en 132KB

Hier vind je gestructureerde en gepagineerde toegang tot diezelfde RFC's. Dus wat op rfc.net als 900KB-bestand werd aangeboden.

Persoonlijk vind ik die tweede toch handiger gebruiken. Ondanks dat ik mijn scherm in portrait-mode 1920pixels hoog kan maken...

Nadat je dat bekeken hebt, wil je werkelijk beweren dat je fatsoenlijk met dergelijke grote teksten kan werken? Ik heb een behoorlijk snelle PC en internet verbinding, maar moest toch wel even wachten voor Firefox die 900KB-html pagina ingeladen had en bruikbaar aanbood. Dergelijke hoeveelheden tekst hoor je imho niet eens op een enkele html-pagina te bieden, laat staan in een enkele reactie van een topic.

Daarnaast weerhoudt je er niets van om een mediumtext veld in de db te limiteren naar minder dan 16 mb, mind you.

De huidige limiet van 64KB wordt idd eerst gecontroleerd voor de boel de DB in gemikt wordt. Verhogen is dus in principe mogelijk door die limiet op bijv 100KB en het veld in de DB er op aan te passen. Ik betwijfel echter of je mij ooit zult kunnen overtuigen van het nut, laat staan de de noodzaak, om die velden groter dan zo'n 512KB of 1MB te maken.
Zelfs de 64KB-in-een-posting ben ik niet van overtuigt, domweg omdat je zelfs een dergelijke hoeveelheid tekst al dmv hyperlinking moet zien te structureren en het dan relatief weinig uitmaakt of je dan twee reacties van 40KB elk of een van 80KB hebt geplaatst.

Een wiki zit er aan te komen, maar volgens mij is het niet nodig de limiet op te hogen. Het is tenslotte, mede om deze reden, niet verboden om meerdere reacties achter elkaar te plakken. Maar ik zou toch degenen die het nodig vinden dergelijke lappen te schrijven op willen roepen te kijken of het ook met minder tekst evenveel informatie kan bevatten.

[NMe]

ACM schreef op zaterdag 10 september 2005 @ 23:37:
De langste topics (je weet wel, die in DC en HC crewfora) nu zijn vziw nog altijd geen 16MB in totaal, dus een dergelijke hoeveelheid tekst toelaten voor een enkele reactie vind ik veel te veel.

Dat MySQL default 16MB toelaat wil nog niet zeggen dat React dat ook moet doen. Een verdubbeling van de huidige 64KB lijkt me dus geen probleem als limiet?

[ACM]

Anoniem: 26306 schreef op zaterdag 10 september 2005 @ 23:27:
Toevallig heb ik zelf flink lopen knoeien met MediaWiki, en daarvan kan ik wel melden dat het goed te "skinnen" is, maar dat ik geen flauw idee heb van hoe goed het met de bestaande/komende GoT/FP accounts te koppelen is.

Spider007 probeert, bijgestaan door mijzelf, MediaWiki bruikbaar te maken met de login-faciliteiten van React. Hij heeft MediaWiki zelf al draaiend onder de noemer GoT Wiki en het is dus de bedoeling dat die DB hier ergens onder de tweakers.net-vleugels komt te draaien.

FYI: ik heb zelf een kleine testomgeving met een op de GoT layout gebaseerde skin, waarin ik de FAQ's en voorwaarden heb geplakt, bij wijze van test.

Die skin klinkt interessant

Het lijkt me duidelijk dat ik er best over wil meedenken als jullie er aan toe gaan komen, maar op dit moment heb ik geen idee van de structuur van de database tabellen zoals deze na de merge gaat worden. Ook weet ik niet of bijvoorbeeld Omega iets kan op dat gebied, zoals zoeken in een forum, frontpage posts en in de wiki?

Die structuur gaat voorlopig niet veranderen. De merge is meer op een software laag boven de DB dan daadwerkelijk in de DB zichtbaar. Een van de dingen die nog op een long-term Todo staat is om de frontpage-zoekmachine te vervangen door Omega/Xapian. In principe is het dan mogelijk zoekresultaten uit meerdere databases te koppelen, maar dat is iets dat ik daarna pas wil onderzoeken (interface-technisch, de Omega/Xapian kunnen het al).

Maar voor ik er zelf nog veel meer tijd aan besteed (niet dat ik dat zo vreselijk vind), is het een reële optie om MediaWiki (of soortgelijke software) te gebruiken? Of is het waarschijnlijker dat er iets anders (maatwerk) ontwikkeld gaat worden? Zijn er al concrete plannen? Hebben jullie zelf al dergelijk onderzoek gedaan? Heeft het zin als ik uitzoek of het te doen is (en of het is toegestaan) om MediaWiki zo aan te passen dat hij de gebruikers en/of rechten uit een andere database kan halen? Etc?

Zie hierboven
MediaWiki staat nu vziw bovenaan Spider007's lijstje en daarmee automatisch ook op de mijne. Maatwerk is imho vooralsnog te veel werk, zeker omdat het werken in Wiki's een hele andere gedachtengang vereist dan forums en CMS-en. De concrete plannen lopen vooralsnog vooral spaak op het niet-triviaal zijn van een integratie van een ander login-systeem met MediaWiki, als het dat wel was geweest had het al beschikbaar geweest
Als jij het leuk vind om uit te zoeken hoe je zoiets met een externe database van gebruikers en sessies kan laten werken, graag Misschien doe je wat overlap met Spider's werk, maar echt ver was hij nog niet gekomen (tenzij ie ondertussen weer verder is).

-NMe- schreef op zaterdag 10 september 2005 @ 23:44:
Dat MySQL default 16MB toelaat wil nog niet zeggen dat React dat ook moet doen. Een verdubbeling van de huidige 64KB lijkt me dus geen probleem als limiet?

Volgens mij staat die vraag al beantwoord in de reactie die je quote?

Owja, niet vergeten dat het ons toch al gauw meer dan 4-6 uur downtime kost om die reactietabellen aan te passen.

[ Voor 8% gewijzigd door ACM op 10-09-2005 23:49 ]

[Anoniem: 26306]

ACM schreef op zaterdag 10 september 2005 @ 23:48:

Spider007 probeert, bijgestaan door mijzelf, MediaWiki bruikbaar te maken met de login-faciliteiten van React. Hij heeft MediaWiki zelf al draaiend onder de noemer GoT Wiki en het is dus de bedoeling dat die DB hier ergens onder de tweakers.net-vleugels komt te draaien.

Mooi, ik vermoedde al zoiets.

Die skin klinkt interessant

Dan krijg je een linkje van me. Mind you, het is het resultaat van even hobby'en, paar uurtjes werk. Finetunen en testen zal uiteraard ook de nodige tijd gaan kosten. Maar de output van MediaWiki lijkt er zeer geschikt voor.

Die structuur gaat voorlopig niet veranderen. De merge is meer op een software laag boven de DB dan daadwerkelijk in de DB zichtbaar. Een van de dingen die nog op een long-term Todo staat is om de frontpage-zoekmachine te vervangen door Omega/Xapian. In principe is het dan mogelijk zoekresultaten uit meerdere databases te koppelen, maar dat is iets dat ik daarna pas wil onderzoeken (interface-technisch, de Omega/Xapian kunnen het al).

Ook mooi. Let er trouwens op dat Spider.007 met MediaWiki 1.3.x werkt. En dat terwijl er in 1.4.x een speciale plugin class is voor externe authenticatie, of iets dergelijks. Het lijkt mij dat dat ervoor moet zorgen dat het nog enigszins eenvoudig te doen is zonder in de MediaWiki code te gaan zitten porren.

MediaWiki staat nu vziw bovenaan Spider007's lijstje en daarmee automatisch ook op de mijne. Maatwerk is imho vooralsnog te veel werk, zeker omdat het werken in Wiki's een hele andere gedachtengang vereist dan forums en CMS-en. De concrete plannen lopen vooralsnog vooral spaak op het niet-triviaal zijn van een integratie van een ander login-systeem met MediaWiki, als het dat wel was geweest had het al beschikbaar geweest

Ik neem aan dat je bedoelt dat er goed gekeken zou moeten worden naar wie wat precies mag, etcetera. Het inloggen zelf lijkt met met die AuthPlugin class goed te doen. Dat zal ik dus in elk geval even gaan testen.

Als jij het leuk vind om uit te zoeken hoe je zoiets met een externe database van gebruikers en sessies kan laten werken, graag Misschien doe je wat overlap met Spider's werk, maar echt ver was hij nog niet gekomen (tenzij ie ondertussen weer verder is).

Mooi, dan pruts ik lekker verder

[NMe]

ACM schreef op zaterdag 10 september 2005 @ 23:48:
Volgens mij staat die vraag al beantwoord in de reactie die je quote?

Ervanuitgaande dat je dit bedoelt:

Ik betwijfel echter of je mij ooit zult kunnen overtuigen van het nut, laat staan de de noodzaak, om die velden groter dan zo'n 512KB of 1MB te maken.

Zo groot zullen ze nooit hoeven worden. Posts komen nu al zelden boven de 64KB, en het lijkt me heel sterk dat er ooit iemand tegen een limiet van 128KB aan zal lopen.

Zelfs de 64KB-in-een-posting ben ik niet van overtuigt, domweg omdat je zelfs een dergelijke hoeveelheid tekst al dmv hyperlinking moet zien te structureren en het dan relatief weinig uitmaakt of je dan twee reacties van 40KB elk of een van 80KB hebt geplaatst.

Dan moet een topicstarter van een (potentiëel?) groot topic dus altijd twee posts reserveren. Ten eerste doet niemand dat, en ten tweede weten veel mensen niets van die limiet; die zien ze pas als ze ertegenaan lopen. Technisch gezien is het verdelen over meerdere posts dus wel te doen, maar vanuit praktisch oogpunt is het eigenlijk alleen bruikbaar in FAQ's.

Owja, niet vergeten dat het ons toch al gauw meer dan 4-6 uur downtime kost om die reactietabellen aan te passen.

Even wachten tot de merge, als de site toch al down is, lijkt me geen probleem?

[ACM]

-NMe- schreef op zondag 11 september 2005 @ 01:42:
Zo groot zullen ze nooit hoeven worden. Posts komen nu al zelden boven de 64KB, en het lijkt me heel sterk dat er ooit iemand tegen een limiet van 128KB aan zal lopen.

Maar het probleem blijft dat het nog steeds eigenlijk wel wat te veel informatie voor een enkele reactie is. Dat soort informatie, zeker die van het voorbeeld uit de topicstart, hoort in een of andere kennisopslag, niet weggestopt in een topicstart.

Even wachten tot de merge, als de site toch al down is, lijkt me geen probleem?

Nou... als we die merge gaan uitvoeren, gaan we alleen die merge uitvoeren. En niet ook gelijk nog even tig andere klusjes.
Bovendien was het antwoord op een vraag die suggereerde dat we "zolang er geen wiki oid is, even die limiet kunnen verhogen". En om dan te gaan wachten op iets anders?

[Anoniem: 144949]

hmm dubbelpost, sorry

[ Voor 98% gewijzigd door Anoniem: 144949 op 13-09-2005 12:00 ]

[Anoniem: 144949]

Momenteel heeft de persoon die de 2de post heeft in het topic aangeboden om een stuk van de topic start over te nemen zodat de hoeveelheid toch verdeeld kan worden over 2 posts. Ik heb dan ook het stuk vernoemd, waar het minste kans is dat er aanpassingen of aanvullingen op moeten gemaakt worden, om over te nemen in zijn post. Dus voorlopig is het probleem op een kunstmatige (en niet al te ideale) manier opgelost.

Met de kennis die ik nu heb zou ik het (in het vervolg) als volgt aanpakken:

Voordat deel X gesloten wordt, zou ik elk blokje tekst (van de topic start)in een apparte post schrijven, en al deze posts posten als laatste in deel X (vervolgens ook nog een aantal posts reserveren voor eventuele stukjes tekst die erbij komen). Dan maak ik deel X+1 aan waarin ik in de topic start, alle titeltjes van alle blokjes tekst zet, om deze titeltje te linken aan de respectievelijke posts in deel X. Zo wordt deel X zodanig beperkt in lengte dat je niet/amper moet gaan scrollen, en blijft alles nog overzichtelijk (in de topic start blijft nog een overzicht van welke info er ter beschikking is.).

-> is dit een acceptabele manier om de zaak aan te pakken? Zijn er betere alternatieven die hetzelfde resultaat geven met dezelfde overzichtelijkheid? (en er rekening meehouden dat ik niet echt een 'code'-kenner ben...!! )

[ Voor 7% gewijzigd door Anoniem: 144949 op 11-09-2005 12:27 ]

[chem]

ACM heeft het meeste al verteld, maar voor mij redenen om niet over de 64 kb te gaan:
De volgende grens is 16 mb; een 16 mb lap tekst aan RML parsen vergt een enorme hoeveelheid geheugen (iig bij onze huidige implementatie) - de php limiet moet dan enorm omhoog wat bij een verkeerde for-loop ook betekent dat je zomaar je geheugen kan laten volstromen.
De grens is ook van belang bij het parsen door de templates: met max 1000 per pagina en max 16 mb per bericht... reken maar uit hoe groot iemand een thread kan laten worden. Met 1000 * 64 kb is dat OOK vreselijk veel maar zou nog te behappen zijn (64mb als m'n berekening klopt).

En daarbij heb ik bijna nog nooit iemand tegen de 64kb grens zien aanlopen. Dat is zo belachelijk veel output voor 1 bericht, ik kan me niet voorstellen welk nut dat dient...

[.oisyn]

Jullie hebben het steeds over 16 mb per bericht, maar het is puur een artificiele grens omdat er simpelweg een grens moet zijn. Maar niet iedereen gaat 16 mb posts maken. Sterker nog, ik durf wel te beweren dat niemand 16 mb posts -of ook maar 1 mb posts- gaat maken. Het is dan ook nutteloos om te zeggen dat alles op z'n bek gaat met die 16 mb limiet, en dat een volle thread met 16 mb posts niet te doen is (nee, is niet te doen, maar een volle thread met 64k posts is ook niet te doen, het punt is echter dat die threads niet bestaan en ook nooit zullen bestaan). Ik vind 64k persoonlijk net te weinig, limit het dan op 512k of 256k als je er zonodig geen 16mb limit op wilt hebben, maar komen met argumenten dat threads vol met 16 mb posts niet te doen zijn spoort niet helemaal omdat simpelweg niemand die posts maakt.

ACM schreef op zaterdag 10 september 2005 @ 23:37:
Voor jou en andere mensen ter referentie: een pagina van bijna 1MB aan html. En dan voor de gein ook nog enkele RFC-pagina's van tientallen KB's: 51KB, 68KB en 132KB

Ik moet zeggen dat ze minder informatie bevatten dan ik dacht voordat ik op de link klikte, dat is zeker niet het effect dat je wilde bereiken? . Maar ter referentie voor jou: doe eens een db query van de gemiddelde post lengte hier op het forum, of wellicht alleen in de techfora. Of zelfs alleen voor W&L, ik vermoed dat daar gemiddeld de langste posts worden gemaakt.

[ Voor 33% gewijzigd door .oisyn op 13-09-2005 11:58 ]

[dawuss]

Nu ja, het hangt er natuurlijk een beetje vanaf wat er precies mis gaat bij threads van 1000 pagina's met 16MB per post. In de praktijk zal het nooit voorkomen, maar je weet nooit wie het toch even wil proberen

[.oisyn]

Ik wil dat ook best proberen met de huidige limiet hoor, dan zal het ook wel op z'n gat gaan (en je bedoelt natuurlijk een thread van 1000 posts gezien met 1000 posts per pagina, niet een thread van 1000 pagina's aangezien de postlengte in dat opzicht niet zoveel invloed heeft)

[ Voor 50% gewijzigd door .oisyn op 13-09-2005 12:08 ]

[ACM]

.oisyn schreef op dinsdag 13 september 2005 @ 11:55:
Jullie hebben het steeds over 16 mb per bericht, maar het is puur een artificiele grens omdat er simpelweg een grens moet zijn. Maar niet iedereen gaat 16 mb posts maken. Sterker nog, ik durf wel te beweren dat niemand 16 mb posts -of ook maar 1 mb posts- gaat maken. Het is dan ook nutteloos om te zeggen dat alles op z'n bek gaat met die 16 mb limiet, en dat een volle thread met 16 mb posts niet te doen is (nee, is niet te doen, maar een volle thread met 64k posts is ook niet te doen, het punt is echter dat die threads niet bestaan en ook nooit zullen bestaan). Ik vind 64k persoonlijk net te weinig, limit het dan op 512k of 256k als je er zonodig geen 16mb limit op wilt hebben, maar komen met argumenten dat threads vol met 16 mb posts niet te doen zijn spoort niet helemaal omdat simpelweg niemand die posts maakt.

Maar wat is nou eigenlijk je argument voor het verhogen van de limiet? Behalve dus "het is technisch niet nodig dus moet moet de limiet hoger".

Want je doet net of ik als enige argument heb gegeven dat het technisch wat vervelend kan worden met postings van 16MB. Dat was juist een van mijn minder belangrijke argumenten ertegen.

Ik moet zeggen dat ze minder informatie bevatten dan ik dacht voordat ik op de link klikte, dat is zeker niet het effect dat je wilde bereiken? .

Het gaat mij er om dat het een zwik tekst is die helemaal niet handig door te lezen is. Domweg omdat het een lang stuk tekst is. Dat het ook nog eens enorm bloated teksten zijn, zoals gebruikelijk bij RFC's maakt verder weinig uit

Maar ter referentie voor jou: doe eens een db query van de gemiddelde post lengte hier op het forum, of wellicht alleen in de techfora. Of zelfs alleen voor W&L, ik vermoed dat daar gemiddeld de langste posts worden gemaakt.

De laatste 50000 reacties op het forum hadden gemiddeld een lengte van 523 karakters aan ruwe tekst en 753 aan HTML. De kleinste was 1 karakter (hmm een bug?) en de grootste 59654 aan html. Maar hoe onderbouwt dat precies jouw argument? Ik weet heus wel dat men dan niet ineens langere berichten gaat posten, maar dat is dan ook een van de redenen dat we ook nauwelijks nut zien in het verhogen van die limiet.

[.oisyn]

ACM schreef op dinsdag 13 september 2005 @ 12:22:
[...]

Maar wat is nou eigenlijk je argument voor het verhogen van de limiet? Behalve dus "het is technisch niet nodig dus moet moet de limiet hoger".

Omdat, zoals nu weer blijkt, iemand last heeft van de huidige limiet van 64k, die ik (voor de 3e keer) persoonlijk te klein vind. Die kun jij niet te klein vinden, het is slechts een mening dus dan zijn we uitgepraat , maar dat is niet het argument dat wordt gegeven. Ik heb ook wel eens iets proberen te posten wat net te lang was, ik weet alleen niet meer wat dat was maar ik weet nog wel dat ik het vervelend vond. Ik heb op mijn eigen forum ook expres niet voor een 64k limiet gekozen maar voor de 16mb.

Want je doet net of ik als enige argument heb gegeven dat het technisch wat vervelend kan worden met postings van 16MB. Dat was juist een van mijn minder belangrijke argumenten ertegen.

Ik vind "dan moet je je tekst beter structureren" zoeken naar argumenten die overeen komen met je mening, ipv je mening vormen aan de hand van de argumenten (alsof je de structuur van een lap tekst kunt afmeten aan z'n lengte, ik vind het wat kort door de bocht), maar desalniettemin doe ik niet net alsof je alleen die argumenten heb gegeven, dat zijn slechts de argumenten die ik probeer te ontkrachten.

De laatste 50000 reacties op het forum hadden gemiddeld een lengte van 523 karakters aan ruwe tekst en 753 aan HTML. De kleinste was 1 karakter (hmm een bug?) en de grootste 59654 aan html. Maar hoe onderbouwt dat precies jouw argument?

Er wordt gesuggereerd (in deze draad, niet per se door jouw persoonlijk) dat bij een limiet van 16mb alles in de soep loopt, wat ik nogal onzin vond en probeerde duidelijk te maken aan de hand van die getallen.

Hoe ik het zie: behalve van een aantal uur downtime (valide punt overigens!) zie ik geen nadelen maar wel voordelen aan het verhogen van de limiet, temeer ook omdat ik eigenlijk vind dat er theoretisch geen maximum zou moeten zijn (in de praktijk wordt dat wat anders uiteraard, maar tegen de 64k wordt al eens tegenaan gelopen, zoals nu ook weer blijkt).

[djluc]

Het verhogen van de limiet is gewoon onzin omdat het bijna niet meer goed te lezen is. Dit punt maakt ACM heel duidelijk. Het probleem is echter dat het niet mogelijk is om bijvoorbeeld een WIKI pagina in een startpost te integreren of iets dergelijks. Dan zou de informatie gewoon op een goede plaats staan en is deze toch direct in de startpost te lezen. Al is het maar een iframe tag o.i.d. wat mij betreft. Nu staat veel informatie ook meerdere malen in de database wat ook zonde is van de ruimte.

[curry684]

chem schreef op zondag 11 september 2005 @ 12:34:
En daarbij heb ik bijna nog nooit iemand tegen de 64kb grens zien aanlopen. Dat is zo belachelijk veel output voor 1 bericht, ik kan me niet voorstellen welk nut dat dient...

* curry684 wijst chem liefjes op dit topic, dat was ook als 1 post bedoeld ooit

[.oisyn]

djluc schreef op dinsdag 13 september 2005 @ 12:53:
Het verhogen van de limiet is gewoon onzin omdat het bijna niet meer goed te lezen is.

Nee, dát is onzin (omdat het kort door de bocht is, zoals ik al eerder zei) wat curry zojuist bewezen heeft met z'n link (die jij helaas niet kunt lezen, maar het is een niet eens zo'n heel lange post met duidelijk leesbare en goed behapbare informatie)

[ Voor 7% gewijzigd door .oisyn op 13-09-2005 13:29 ]

[ACM]

.oisyn schreef op dinsdag 13 september 2005 @ 12:43:
Ik vind "dan moet je je tekst beter structureren" zoeken naar argumenten die overeen komen met je mening, ipv je mening vormen aan de hand van de argumenten (alsof je de structuur van een lap tekst kunt afmeten aan z'n lengte, ik vind het wat kort door de bocht)

Je kan je natuurlijk afvragen of de ruimte te klein is of dat de tekst te lang is.
Ik denk dat de hoeveelheid informatie die in dergelijke postings aangeboden wordt domweg te veel is om op een enkele pagina te vertonen. Misschien heb je gelijk dat het "iets" meer mag zijn, dat de limiet op 100kb tekst zou moeten liggen ofzo, maar dan lopen we weer tegen technische beperkingen aan het huidige opgeslagen veld en in de react-code.
Beide aanpassingen kosten tijd en de eerste dus ook enkele uren downtime.

Dit soort informatie, van de grote topics, hoor je imho zo goed mogelijk te structureren, zodat gebruikers er des te meer aan hebben. En volgens mij doe je er ook goed aan een beter geschikt medium ervoor te gebruiken dan domweg alles in een posting te proppen, na 1000 reacties de boel bij te werken en dan opnieuw alles in een (dan nog wat grotere) posting te proppen.
Uiteraard is het zo dat we nu zo'n medium nog niet aanbieden, maar dat zegt nog niet dat we nu dan maar als tijdelijke oplossing die limiet moeten verhogen.
Want zodra het andere medium er is, is de verhoging van die limiet nog een stuk minder zinvol. Dat W&L-mensen goed over de lengte van hun discussies na moeten denken is alleen maar postief, toch?

.oisyn schreef op dinsdag 13 september 2005 @ 13:29:
Nee, dát is onzin (omdat het kort door de bocht is, zoals ik al eerder zei) wat curry zojuist bewezen heeft met z'n link (die jij helaas niet kunt lezen, maar het is een niet eens zo'n heel lange post met duidelijk leesbare en goed behapbare informatie)

Die posting van Curry is imho een uitzondering, de eerste van de twee reacties is een enorme verzameling links, en ja... dan gaat het kwa resulterend html natuurlijk hard.
De meeste lange topics en FAQ's beginnen zijn echter vziw meer dan dat, o.a. lappen tekst met uitleg, stukjes vraag-en-antwoord etc.

Het begin van die eerste reactie bewijst trouwens dat het prima in de huidige opzet met 2 reacties werkt Curry heeft daarbij ook nog eens een logische scheiding weten te vinden, waardoor het nog weer handiger is, hij hoeft nu ook maar de helft van de lap tekst te bewerken als ie een wijziging heeft

[ Voor 24% gewijzigd door ACM op 13-09-2005 13:36 ]

[Anoniem: 144949]

Is er dan iets in het vooruitzicht dat er zo'n medium (op korte termijn) gaat aankomen?

[ACM]

Ja, het lijkt redelijk goed te werken. Dus het wordt tijd voor puntjes op itjes en dan een pilot met de GoT-crew.

[Tanuki]

[ikbendom]
Je kunt het limiet wel verhogen naar 16 MB, maar het limiet van het kolomtype waar het in wordt opgeslagen is 16 MB. Dat wil toch niet zeggen dat wanneer er een topicstart wordt gemaakt je persé aan het limiet moet zitten? Als je dan een post maakt van 23 KB, dan wordt er ook maar 23 KB schijfruimte gebruikt (+ 1 byte extra dan ofzo). Pas wanneer iemand ook echt een post van 16 MB gaat maken (wat niet voor gaat komen, neem ik aan ) is die post 16 MB groot. En dan kun je nog het limiet van MyReact aanpassen naar bijv. 256 KB, zodat je nooit zulke lappen tekst krijgt.

Ik weet niet in hoeverre bovenstaande te realiseren is, maar het lijkt mij dat je in MyReact wel kunt veranderen wat het limiet in bytes per post is (lijkt me sterk dat een script op een limiet van een databaseserver werkt).


Sorry als ik iets raars zeg, maar daar excuseer ik me dan maar alvast voor.
[/ikbendom]

[Rac-On]

ik zie hier steeds als argument voorbij komen dat je tekst die zo lang is moet structureren, maar als ik een lang stuk tekst pak en die gaan verdelen in verschillende paragraafen, titeltjes erbij, anchors ertussen, inhoudsopgave erboven, in een tabelletje, rij''en in verschillende kleuren e.d., dan ben ik toch alleen maar meer tekst aan het toevoegen??

met meer bytes tot je beschikking heb je simpelweg meer ruimte om met allerlei frutsels (zie bovengenoemde) je tekst leesbaar te houden. Vind ik een mooiere oplossing dan 2 posts pakken.

en met die 16mb moeten we echt kappen, het gaat om een verhoging van de limiet naar 128 kb of iets vergelijkbaars

[ Voor 11% gewijzigd door Rac-On op 13-09-2005 13:55 ]

[leuk_he]

CelestialCelebi schreef op dinsdag 13 september 2005 @ 13:53:
[ikbendom]
Je kunt het limiet wel verhogen naar 16 MB, maar het limiet van het kolomtype waar het in wordt opgeslagen is 16 MB. Dat wil toch niet zeggen dat wanneer er een topicstart wordt gemaakt je persé aan het limiet moet zitten? Als je dan een post maakt van 23 KB, dan wordt er ook maar 23 KB schijfruimte gebruikt (+ 1 byte extra dan ofzo)
Sorry als ik iets raars zeg, maar daar excuseer ik me dan maar alvast voor.
[/ikbendom]

[lichtelijk offtopic]
Daarin heb je gelijk. Als er iemand TOCH op het idee komt een lap text vn 16 MB in te voeren kunnen er WEL gekke dingen gebeuren. Dat is het punt. Verder kan er links of recht stukjes software staan die niet op het idee komen meer als 64 Kib te lezen, of grove performance problemen veroorzaken.

Het enige dat vastgeslte d is dat elke post straks 1 byte extra gaat gebruiken. Niet echt dramatisch op het grote geheel.
[/]

[Erkens]

rac-on schreef op dinsdag 13 september 2005 @ 13:54:
maar als ik een lang stuk tekst pak en die gaan verdelen in verschillende paragraafen, titeltjes erbij, anchors ertussen, inhoudsopgave erboven, in een tabelletje, rij''en in verschillende kleuren e.d., dan ben ik toch alleen maar meer tekst aan het toevoegen??

zolang je geen titels kan maken met de RML hier valt er weinig te verdelen imo.
En die tabellen met die kleuren die je soms in die "o zo mooie" start posts ziet

met meer bytes tot je beschikking heb je simpelweg meer ruimte om met allerlei frutsels (zie bovengenoemde) je tekst leesbaar te houden. Vind ik een mooiere oplossing dan 2 posts pakken.

de vraag is of het met al die frutsels wel leesbaarder is

en met die 16mb moeten we echt kappen, het gaat om een verhoging van de limiet naar 128 kb of iets vergelijkbaars

die 16mb kwam doordat dat MySQL de eerst volgende limiet is, niet echt een issue iig

[ACM]

rac-on schreef op dinsdag 13 september 2005 @ 13:54:
met meer bytes tot je beschikking heb je simpelweg meer ruimte om met allerlei frutsels (zie bovengenoemde) je tekst leesbaar te houden. Vind ik een mooiere oplossing dan 2 posts pakken.

Mooier misschien wel.

Maar goed, we hebben nog even intern overlegd en het is ons de paar uur downtime die het zal gaan kosten niet waard. Ik heb me overigens mede vanwege dit topic extra ingezet om de wiki werkbaar te krijgen en met de skin die cheatah al in elkaar geklust had ziet het er ook nog eens redelijk goed en bij onze layout passend uit.
Daarmee is volgens mij de belangrijkste reden om nog lange reacties te posten verdwenen en wordt het nog uitzondelijker en dus nog minder interessant om de downtime eraan te geven.

[Anoniem: 144949]

Dat vind ik een mooie oplossing!
Wordt het dan mogelijk om zoals ik dacht te doen: in de topic start in het forum zelf: alle titeltjes zetten die elk naar hun respectievelijke stukje tekst linken dat op zich dan in die wiki staat? En ga ik daar dan ingewikkelde codes voor moeten kennen, of gaat dat makkelijk zijn om te doen?

[ Voor 17% gewijzigd door Anoniem: 144949 op 13-09-2005 14:46 ]

[sanfranjake]

Ik gok dat een [wiki=] tag naast de bestaande rml tags zo geklust is als het wiki gestart is

[Erkens]

sanfranjake schreef op dinsdag 13 september 2005 @ 14:49:
Ik gok dat een [wiki=] tag naast de bestaande rml tags zo geklust is als het wiki gestart is

het zou natuurlijk ook mooi zijn dat als je de URL paste dat hij dan ook automagisch de titel neerzet, net zoals met topics (een feature die ook wel handig zou zijn voor de frontpage)

maar dat is allemaal voor latere zorg lijkt me

[ACM]

sanfranjake schreef op dinsdag 13 september 2005 @ 14:49:
Ik gok dat een [wiki=] tag naast de bestaande rml tags zo geklust is als het wiki gestart is

Dat is wel nuttig, [wiki=TitelVanPagina] ofzo.

Erkens schreef op dinsdag 13 september 2005 @ 14:54:
het zou natuurlijk ook mooi zijn dat als je de URL paste dat hij dan ook automagisch de titel neerzet, net zoals met topics (een feature die ook wel handig zou zijn voor de frontpage)

Aangezien de titel al in de url staat zou dat op de naieve manier iig vrij eenvoudig moeten kunnen

[djluc]

Wat dan als de Wiki pagina veranderd? Worden die gegevens dan weer up to date getoond?

[ACM]

Nee, net als de topics in GoT etc. Die links gaan we echt niet allemaal bijhouden en bijwerken als er wat wijzigt.

[.oisyn]

Nee, maar dat is met topics ook niet zo. Als ik link naar Probleem! Maximaal aantal tekens?, en ik pas na het plaatsen van deze post de titel van de topic aan, dan veranderd de tekst niet automatisch mee ofzo

[Anoniem: 34169]

Misschien ben ik blind, maar volgens mij heeft nog niemand opgemerkt dat van die 64k karakter een hoop gaat zitten in simpelweg opmaak-tags, en dus geen zichtbare informatie is. Er staan in de betreffende startpost een hoop links, en die worden met de volgende code gemaakt:

code:

[url=http://dit.iseenlink.naar/eenartikel]Artikel zusenzo[/url]

Het enige dat aan informatie wordt verstrekt is 'Artikel zusenzo', de code bevat 46 tekens die niemand ziet, 3x zoveel als de zichtbare tekst.

Aangezien in 'grote topics' tegenwoordig vrijwel altijd met tabellen gewerkt wordt lijkt het me veilig om te stellen dat nog niet eens de helft die 64k zichtbaar is. Dus met 'teveel info' zal het wel loslopen. Juist het aanbrengen van structuur kost zoveel tekens.

[ Voor 7% gewijzigd door Anoniem: 34169 op 18-09-2005 17:13 ]

[Erkens]

Anoniem: 34169 schreef op zondag 18 september 2005 @ 17:13:
Aangezien in 'grote topics' tegenwoordig vrijwel altijd met tabellen gewerkt wordt lijkt het me veilig om te stellen dat nog niet eens de helft die 64k zichtbaar is. Dus met 'teveel info' zal het wel loslopen. Juist het aanbrengen van structuur kost zoveel tekens.

en dus moet je die tabellen niet gebruiken voor "stuctuur" (die je daar juist niet meer maakt)
Er moeten gewoon tags als [h1] .. [h6] enzo komen, dan pas kan je structuur aanbrengen