En dum klient, en ännu dummare server

SymbianOS är ett sådant där system som bygger på en mikrokärna. Precis som i andra sådana system så finns en massa funktionalitet i servrar, som man kommunicerar med genom att skicka meddelanden till. Vill man öppna en fil så skickar man ett meddelande till filservern. Vill man rita något i ett fönster så skickar man ett meddelande till fönsterservern. Vill man ha tag på sprit så skickar man ett meddelande till spritservern. Man behöver i och för sig inte ta hand om de här detaljerna i vanliga fall, utan man går igenom ett klientlib som sköter själva meddelandeskickandet.

Ska man implementera egna servrar, vilket man är tvungen att göra ganska ofta, så är man dock tvungen att gå i närkamp med klient/server-ramverket. Man skulle kunna föreställa sig att ett OS som är så baserat kring klient/server-kommunikation skulle ha väldesignade mekanismer för detta, men det är trots allt Symbian vi snackar om här. Jag tänkte att vi skulle ta en liten titt på det knarkrus som är serversidans gränssnitt mot inkomna meddelanden, en klass om i SymbianOS 9 heter RMessage2.

Ett meddelande kan innehålla max fyra argument. Dessa plockar man ut med metoderna Int0(), ..., Int3(), om de är numeriska, eller Ptr0(), ..., Ptr3() om de består av strängar. Det finns ingen form av typkontroll, så både klienten och servern måste ha koll på vilka typer det är som gäller för de olika argumenten. Lustigt nog finns det inga uppgifter om hur många argument klienten har valt att skicka med i RMessage2. Det finns alltså inget sätt att kolla om klienten har gjort ett korrekt anrop eller ej. Jag skulle tro att anledningen till den här designen är antingen att man ville spara utrymme (det skulle faktiskt ta hela 2 bitar för att representera antalet argument) eller för att det inte var tänkt som ett öppet system från början. I en situation där man jobbar flera stycken tillsammans på ett projekt kan det här vara ganska irriterande. Säg att någon lägger till ett nytt argument till en funktion på servern. Det finns ingen som helst kontroll på att klienten skickar vettiga argument, så buggarna som uppstår är jobbiga att fixa. Det här skulle vara okej om det fanns något sätt att generera stubbar för att skicka och ta argument, men så roligt ska vi inte ha. Det här är SymbianOS, så vi marshallar våra argument själva.

Jag tänkte peka på en sak till i RMessage2 som jag finner ganska roande och säger en hel del om hur det går till när man designar API:er på Symbian. I SymbianOS 9 finns det ett capability-baserat säkerhetssystem, d.v.s. en applikation har rättighet att göra olika saker, baserat på vilka capabilities den har. En server måste alltså kunna kolla vilka capabilities en klient som gör ett anrop har, så att den kan avgöra om den har rätt att be om en tjänst. I RMessage2 använder man HasCapability() (eller HasCapabilityL()) för att kolla capabilities. Notera dock att det finns två överlagrade versioner av varje anrop. Med den ena kollar man om klienten har en viss capability. Med den andra kan man kolla två capabilities samtidigt. Varför någon skulle vilja ha den andra versionen är en gåta för mig. Och om man nu kan vilja kolla två capabilites, varför inte tre? Tja, i så fall får man göra flera anrop. Och jobbar man på Symbian så får man uppenbarligen gratis crack till morgonkaffet. Gött.