Peter Wagemans

Bedankt Menno, de boosheid is momenteel een beetje aan het overslaan in onverschilligheid. Misschien is dat ook niet goed, maar ik heb er in elk geval minder last van.

Status update: we zijn er ondertussen helemaal technisch uit, en deze thread resulteerde in een ongelooflijk handig tooltje. Samen met Mr. Watson en Andries gooiden we alle ideeën en code bij mekaar, en we hebben dit donderdagavond gepresenteerd in de dotfmp 1/12 video meeting. Geheel onverwacht waren er een aantal mensen helemaal niet blij met wat we deden. Ik besefte niet goed wat er gebeurde eigenlijk. Er werd betwijfeld of dit wel open source moest zijn en zo. Andere mensen hadden het over werknemers die niet zomaar know-how mogen delen - dit terwijl het over een paar regels JavaScript code gaat die al jaren geleden in de community gedeeld zijn - en dat was toen helemaal geen probleem omdat niemand het nut ervan in zag. Achteraf, en na wat dialoog met Andries en een andere vriend, is het me duidelijk dat heel wat mensen Open Source perfect OK vinden, zolang het maar geen pad kruist met hun eigen commercieel werk. Dat is in mijn opinie kortzichtig. En men wilt wel iets delen, maar verwacht daar altijd "eternal fame & glory" voor, een soort van marketing tool voor je business. Als Open Source concurrentie wordt, moet je gewoon creatiever worden dan je bent. Open Source werkt aan twee kanten. En als je alleen deelt als iedereen het kan zien, dan ben je eigenlijk gewoon een egoist. Niemand heeft een probleem dat bijvoorbeeld fullcalendar ( https://fullcalendar.io/license ) een Open Source project is, en niemand heeft er een probleem mee om die code ook in hun commerciele oplossingen te steken. Maar het is voor sommigen wél een probleem als we nieuwe FileMaker functionaliteit onderzoeken, problemen identificeren en oplossingen zoeken, en die know-how met iedereen willen delen. Een beetje absurd eigenlijk. Resultaat: er gebeurd nu voorlopig even niks. Ik moet dit even laten bezinken, en ik probeer de laatste dagen controle te krijgen over een boosheid waar ik niet vanaf geraak. Een video meeting is een goed alternatief op een IRL meeting, maar een muur van intialen waarbij iedereen de camera en micro afzet, en een paar mensen nemen je op de korrel zonder dat iemand reageert, ik kan je vertellen dat dat geen fijne ervaring is.

De processor - het is een ARM processor, geen intel of AMD cpu. Claris moet fms19 specifiek voor deze CPU compileren, ik hoop dat ze het gaan doen, maar acht het weinig waarschijnlijk. Toch niet op korte termijn.

Ik ben eruit aan het geraken in verband met docker. Ik kan nu FileMaker Server 19 als een docker image op mijn Mac draaien, maar er is nog wat werk aan. Ik heb net mijn bevindingen gepost op https://community.claris.com/en/s/question/0D70H000005Brzw/filemaker-server-19-for-centos? Een docker image is denk ik de ultieme manier om CentOS FileMaker Server 19 te draaien.

Het is natuurlijk wel fijn dat het werkt, al is het maar zodat je snel kan zien dat de server draait op je LAN. Ik lees hier iets over qemu voor Raspberry Pi, en de mogelijkheid om een i386 CPU te emuleren. Ik vraag me nu af of je een CentoOS 7 image op die manier kan draaien op een Pi. En ik laat hier ook even in het midden of het zien heeft misschien dat het wel meevalt qua performance. FMS19 in een luciferdoosje is misschien dan toch mogelijk?

Impressionant. Daar zal je wel wat research voor gedaan moeten hebben. Ik vraag me echter eerlijk gezegd af of het nodig is. Als je een server via Bonjour ziet, dan zie je 'm via zijn lokale naam, niet? Dus log je zó in dan klopt de DNS naam niet met het SSL certificaat. Of mis ik hier een truukje?

<rant>We hebben nu tenminste een manier om full versions te downloaden en ook de fmcert file te re-downloaden. Iets dat al veel te lang niet zomaar mogelijk was. De download page verviel na een tijdje, en nieuwe hardware installeren kon niet bij klanten die al een tijdje een bestaande licentie hadden, maar hun download versie niet kon geinstalleerd worden wegens niet compatible. Ik vraag me af of Claris nu het correcte gedaan heeft... en hier een techinfo artikel over gepubliceerd heeft.</rant> Ik ben deze week heel dom geweest. Een Raspberry Pie besteld omdat ik met mijn zotte kop niet besefte dat dit dingejte een ARM processor heeft en daardoor natuurlijk geen FMS19 kan draaien. De kans dat Claris ook een Linux versie voor ARM uitbrengt is denk ik miniem. Zou wél fantastisch zijn: FileMaker Server in een luciferdoosje van minder dan 60 euro. Ideaal voor een POS setup met iPadjes.

Web service en webdirect - running, inderdaad, die OpenJDK installatie was heel goed begeleid. Spijtig dat php en XML volledig gedumpt worden. Hoelang zal de Data API leven? Zet nu in.

2 zaken die niet in orde waren tijdens mijn recente installaties van FMS 19. - Op de Mac ging het fout omdat ik de eerste release probeerde te installeren. Claris heeft toen stilletjes een "a" versie ter beschikking gesteld, die wél werkte. - Op CentOS ging het mis omdat de LicenseCert.fmcert file niet meer OK was. Ons bedrijf had die eind mei gekregen, en blijkbaar waren die certificaten ook niet OK. Voor beide situaties heb je 1 gemeenschappelijk symptoom: de files op de server gaan gewoon niet open. Tip voor het downloaden van een geldig certificaat: https://accounts.claris.com/software/license/#####-#####-#####-#####-#####-#####-##### waarbij je de #### vervangt door je licentienummer. Je komt dan op de download pagina waar je een recente cert file, en ook de laatste full versions kan downloaden.

Ondertussen heb ik de Centos versie ook draaien op mijn Synology DS1819+ als een VM. Ik heb als cruciaal probleem dat de server nog geen files opent. Een beetje als de eerste macOS v19 server release, zelfde symptomen. Maar dit is wel cool hoor

Getest op WIndows 10 (VM) met Cherry 1044, en werkt prima! Dit is zo mooi om te hebben... op macOS is het een redelijk belachelijk probleem dat ervoor zorgt dat dit feestje niet kan doorgaan. Terwijl ik de tekst hieronder schreef, triggerde de event een 2de keer. Zomaar. Dus ik denk dat hier wel wat extra code kan rond geschreven worden. Kunnen we een kaart exit detecteren? Claris moet voor elk framework ( windows user: lees library, dll ) dat ze willen accessen braafjes toelating vragen aan moeder Apple, en moeder vindt dat haar dochter Claris(sa) nogal veel lastige vragen stelt blijkbaar. Ik heb het over de zogenaamde "entitlements", een simpele tekst lijn in de .plist van de applicatie, waardoor de systeemsoftware akkoord gaat met toegang tot het macOS framework dat bijvoorbeeld automatisch kaartlezen toelaat. Het kan dus perfect, maar het mag niet van mama. 3 zaken zijn hier raar: We komen stilaan in een situatie waar de gebruiker niet meer kan beslissen, maar waar Apple beslist wat mag en niet mag. Als een verlichte despoot verbiedt Apple toegang tot de kaartlezer bibliotheek. Het is aan de gebruiker of systeembeheerder om te beslissen of dit kan en mag, en niet aan Apple. Power to the people! Dit terwijl we eigenlijk perfect smarcards kunnen lezen, Apple promote hier om haar systeemsoftware niet te gebruiken. De plug-in kan gewoon de kaart lezen - op een andere manier. Een beetje analoog aan wat de Belgische overheid doet met haar EID Middleware, en net doet of je een smartcard niet kan lezen zonder haar software. Waar zit de security issue met het lezen van een SmartCard? Ik ben benieuwd wat Apple als reden opgeeft. Claris vertelt ons "off the record" dat ze geen toelating krijgen van Apple. Maar zou dit eigenlijk OP tafel moeten gooien, ipv eronder. Als ik het goed begrijp, kan je dus tegenwoordig méér met een iPad en de MBS plug-in, omdat je daar de entitlements zélf kan bepalen in XCode. Dat kan je ook op de Mac, maar dat is natuurlijk niet legaal. Het houdt in dat je de plist aanpast en gewoon opnieuw de applicatie signed. Wat een zootje.

OK, Wim Decorte to the rescue.

Heeft er al iemand geprobeerd om FileMaker Server 19 te installeren op een Catalina machine? Ik probeer dat deze morgen, en de installatie lukt, maar ik kan geen bestanden openen. De web console list de server sample file maar kan 'm niet openen, blijft gewoon op rood icoontje hangen en refresht niet, force refresh geeft file gesloten icoontje. "fmsadmin list files" geeft lege lijst. De server event.log geeft helemaal niets aan.

Ja die revert is waar het echt interessant wordt, event kan niet verplaatst worden nu omdat het record gelocked is in FileMaker, en revert dus terug. Werkt als een speer. Anyway Russel en ik hebben het Get ( ScriptResult ) aan de FileMaker kant helemaal werkend! Je kan dus nu een perform script in webviewer doen, en het scriptresultaat terug krijgen, terwijl je script gewoon blijft verder draaien: Perform Script [ module.doWebViewerScript , parameters: blabla ] set variable #result [ Get ( ScriptResult ] Waarschijnlijk had jij een beetje pech dat het niet werkte toen je het probeerde, want het werkt echt. Als je tijd hebt en je kan je bibliotheek verder completeren met "waitForFileMaker" en "scriptTimeouts" zullen Russel en ik de module verder afwerken en op github zetten.

Gisteren als oefening fullcalendar beginnen te integreren met FileMaker 19. https://www.clarify.net/wvr/fullcalendar/fullcalendar.html geeft je een blanco pagina, maar dat het is ook niet bedoeling dat je dit vanuit je browser opent. Mijn insteek was als volgt: Begonnnen met Carafe, en een standaard deploy Dan beginnen kijken naar de code, en beslist dat ik alle includes zou verhuizen naar https://www.clarify.net/wvr/fullcalendar, gewoon omdat ik er dan goed bij kon, en omdat ik altijd wat last heb met code die beheerd wordt door iemand anders De html verhuis ik tijdens mijn tests naar https://www.clarify.net/wvr/fullcalendar/fullcalendar.html , da's gewoon gemakkelijker dan javascript te zitten wijzigen in FileMaker zélf, en ik kan er gewoon goed aan door die web dir te mappen via smb. BBEdit is niet de beste javascript editor maar ik gebruik 'm als zó lang en dit gaat zeker beter dan in een FileMaker veld te zitten prutsen. Eerste dingetje dat ik deed was een wacht loop inbouwen zodat het FileMaker object kon laden, Russel ( Mr. Watson ) praatte daarover eergisteren in zijn "getting up to speed" sessie, en het was heel belangrijk, jij refereert er ook naar hierboven. Dan een bypass naar een functie loaded() die awaitFileMaker(100) doet, dus 100 milliseconden wacht, en indien FileMaker object laadt ( dus alleen in webviewer ) gaat het FileMaker.PerformScript ( "init calendar" ) uitvoeren, waarop dat FileMaker script de configuratie parameters doorstuurt naar loadCalendar(). Hier dus nog niet jouw wrapper lib gebruikt. Vervolgens loadCalendar aangepast zodat het de kalender initialiseert met de data parameters die we via het script doorgaven: defaultDate, firstDay, editable, enz. echter GEEN events. Initieel wél, maar later heb ik dat veranderd. Ik kon nu het Carafé script volledig laten vallen, en gewoon de URL oproepen, dus al de substitute functies en zo waren niet meer nodig. Cool. Vervolgens wat meer parameters beginnen doorgeven voor de initialisatie, het leek me leuk dat je in FileMaker bepaalt hoe alles er moet uitzien, en niet in de html. Ook de fmp urls eruit gehaald en vervangen door rechtstreekse FileMaker.PerformScript calls, nog steeds jouw wrapper lib niet gebruikt. Knopje voor volgende en vorige maand toegevoegd, en dit confronteerde mij met de event feed, die ik tot hiertoe gewoon voor de maand van de default date had gemaakt. En die natuurlijk niet zomaar events gaat ophalen bij navigatie… Events moesten dus op een andere manier binnenlopen dan bij initialisatie, tijd om wat verder in de fullcalendar docs te kruipen, en de volgende uren heb ik daar ook wel wat tijd gespendeerd. Mede omdat ik in de verkeerde versie van de docs zat (v4), Carafe voorziet dus een oude versie van fullcalendar. Even met v4 gespeeld, maar toen zag ik dat de dingen nog meer braken, dus terug naar v3. In de documentatie https://fullcalendar.io/docs/v3/events-function vond ik een manier om events op te halen via een functie. Dat was events: function( start, end, timezone, callback ) { }, fullcalendar gaat dus zélf beslissen wanneer het data nodig heeft, en FileMaker moet alleen een JSON reply geven voor een gegeven start- en einddatum. En hier komt-ie… nu zie ik waarom @andries die gekke structuur "data callback / error callback" gebruikt, want het maakt ook deel uit van de javascript cultuur. Sorry voor mijn eerder onbegrip, ik ben een beetje gehinderd door jaren code schrijven zonder callbacks. fullcalendar gebruikt weliswaar alleen de success callback, maar in v4 gebruiken ze ook de error callback. Hier dus de event feed die door de wrapper van Andries ongelooflijk elegant wordt: events: function ( start, end, timezone, callback ) { var param = {} ; param.start = start ; param.end = end ; param = JSON.stringify( param ) ; fm.performScript("[web] fetch events", param ) .then ( function ( data ) { callback ( JSON.parse ( data ) ) } ) .catch( function ( error ) { alert("ERROR:" + error ) } ) }, Het is nog niet af, ik denk dat ik alles nu via de fmwapper lib ga laten lopen, dan van ik ook de errors op. Ook tijd voor een design beslissing: events editen via de webviewer en doorgeven aan FIleMaker, of events doorgeven aan FileMaker, daar wijzigen en terug doorgeven aan de webviewer? Er is ook nog iets mis met die awaitFileMaker() routine, ik ga niet 100% OK met die Promise om, Safari is in elk geval niet happy als ik de pagina op die manier laadt.