Visa fullständig version : Plugins till Disgen
DanielBerglund
2013-01-03, 01:30
(Utbrutet från en annan tråd (http://forum.dis.se/vb/showthread.php?1035-Problem-med-GEDCOM-5-import-i-Disgen&p=4210&viewfull=1#post4210))
Till någon kommande version av Disgen skulle det vara intressant att diskutera kring plugins, alltså extra programmoduler som kan installeras "i" disgen och ge extra funktioner. Fenomenet är nog rätt välkänt från t ex webläsare. Exempelvis är möjligheten att se DjVu-bilder från SVAR implementerat med en plugin i webläsarna.
Inom utvecklingsgruppen har vi inte alls, än så länge i alla fall, diskuterat hur sådan plugins ska utformas och vilken funktion de ska tillhandahålla. Det vore bra om vi kunde få en viss tankeverksamhet kring detta så tidigt som möjligt, utan att vi ger något löfte om och när en sådan funktionalitet kan tillhandahållas. Förslagsvis diskuterar vi i den här gruppen och skriver ner mer eller mindre genomarbetade tankar på wikin.
En första fråga är om SQLite-databasen kommer att krypteras eller ej. Om den inte gör det kan man i princip göra ett helt nytt gränssnitt till databasen, oberoende av Disgen.
Plugins till Disgen (wiki) (http://wiki.dis.se/w/index.php/Plugins_till_Disgen)
Kanske var lite snabb att klottra i wikin. Ett alternativ till att bara ge tillgång till särskilda funktioner är att tillåta SQL-satser direkt mot databasen. Är inte säker på att en plugin ska kunna skriva till databasen (insert, update) utan det torde räcka med att ställa frågor (select).
DanielBerglund
2013-01-05, 23:49
Vi har inga planer på att kryptera databasen. Det tror jag bara är slöseri med energi och försvårar felsökning. Däremot blir det säkert så att databasens struktur ändras från version till version utan förvarning, och det får den vara beredd på som skriver program som går direkt mot databasen. Hur vi ska hantera detta så det inte dyker upp en massa skumma extraprogram som har sönder databaserna får vi se med tiden. Idag är inte fallet att vi drunknar i extraprogram precis.. Någon slags "godkänt av DIS"-stämpel borde väl gå att införa och skulle då innebära någon viss minimistandard på versionskontroller och kanske att någon Disgen-utvecklare har granskat koden. Det får blir en senare fråga.
Tanken är annars att man ska gå via en DLL, för det kommer Disgen att göra. Där blir det också ett API som kan ändras eller kompletteras men med tiden borde det gå att hålla det någorlunda stabilt, tänker jag mig.
Om man inte tillåter SQL-frågor via pluginen (DLL:en) behöver man specificera all den information en användare kan tänkas behöva. Är det någon vits att lista dessa funktioner nu? Kan vara lite knepigt för oss som inte är insatta i koden till Disgen. Dessutom ska ju databas-strukturen göras om helt. Vissa standard-funktioner kan man nog klura ut ändå ...
DanielBerglund
2013-01-09, 00:25
Det kanske är bättre att börja i andra änden: vad ska pluginerna kunna göra? Om vi listar ett antal exempel på möjliga plugins (alla tänkbara sådana kan naturligtvis inte förutsägas...) är det lite lättare att se vilka data som pluginerna behöver kunna läsa eller skriva, och vilka "händelser" som behöver rapporteras från Disgen till plugin och tvärtom.
Det första jag tänker på är olika typer av rapporter, släktsammanställningar i olika format och exporter till HTML5, mobil-anpassad webb etc. Statistik-rapporter (utöver det som finns) kräver förmodligen direkt access till databasen. Samma gäller för felsökningsrapporter utöver det Disgen erbjuder.
Kanske ska lägga till rapporter som inte direkt utgår ifrån släkt utan är kopplade till ort, gårdshistoriker osv.
Jag föreställer mig att Disgen skulle kunna antingen åtföljas - eller kompletteras via försäljning - av ett SDK som exponerar lämpligt valda delar av databas och/eller funktionalitet. Ett sådant SDK skulle ge möjlighet - för dem som vill och kan det - att 'tillverka' plug-ins för mer eller mindre generella ändamål. Sådana plug-ins skulle sedan kunna säljas eller skänkas. DIS skulle i ett sådant fall kunna göra Disgen något mindre monolitiskt och i stället ha en bas-Disgen som sedan efter varje användares behov kunde kompletteras med något/några av ett antal 'standard'-plug-ins och/eller något/några utomstående plug-ins.
För övrigt och måhända off-topic: finns nästa Disgens arkitektur och datamodell - åtminstone översiktligt - beskriven i något och för medlemmar läsbart dokument? Utan sådan kunskap är det något svårt att bedöma vilka plug-ins som skulle kunna bli till nytta.
För egen del skulle jag bl.a. gärna kunna göra sökningar där villkoren inte är så begränsade som de är i dag. Enkelt exempel: hitta alla kvinnor som har blodsband till någon viss person och som fött fler än sex barn som vardera fått leva minst tio år.
DanielBerglund
2013-01-29, 22:57
Plugins för sökningar (antingen allmänna "avancerade" sökningar eller specialiserade sökningar) låter som en bra tanke. Plugins kommer givetvis att ha tillgång till hela databasen på ett eller annat vis. Enklast är att till en början enbart tillåta läsning av data. Det låter som att pluginer också behöver ha APIer för att kunna skapa och manipulera söklistor. Som kompensation för att de kanske inte kan skriva data ohämmat i en första version kan man tillhandahålla något gränssnitt som tillåter flaggsättning på personer. Dessutom behövs något som gör att användaren kan använda ett plugin, t ex någon möjlighet att registrera sig någonstans i menystrukturen.
Intressant vore att få reda på vilken den motiverande idén bakom den tänkta plug-in-möjligheten är.
Är det att:
Möjliggöra för DIS att saluföra tilläggsfunktionalitet till Disgen, eller är det att:
Möjliggöra för Disgenanvändare att (oavsett motiv) själva utveckla önskad funktionalitet, eller
Vad annars?
Forumdiskussionen har inte gett svaret.
Christer
2013-01-31, 23:54
Du har helt rätt.
Det är att möjliggöra för Disgenanvändare att utveckla viss önskad funktionalitet. Närmare har vi inte diskuterat ännu.
Man kan också fundera på i vilken utsträckningen en plugin kan påverka (eller utnyttja) gränssnittet, med antavlor etc eller om pluginen får skapa egna widgets inom en canvas, panel eller vad man väljer att kalla det. Pluginen kanske ska få skapa en egen meny etc. En plugin bör också kunna accessa temporära tabeller såsom sökresultat. Det kanske är bäst att plugins annars får hållas med egna databaser om det behövs.
Christer
2013-02-03, 21:30
Man kan också fundera på i vilken utsträckningen en plugin kan påverka (eller utnyttja) gränssnittet, med antavlor etc eller om pluginen får skapa egna widgets inom en canvas, panel eller vad man väljer att kalla det.
Kan du beskriva vad du försöker säga med ett annat språkbruk är du snäll. Kanske mer ur ett verksamhets- än tekniskt perspektiv så ska jag försöka ta till mig vad du är ute efter.
DanielBerglund
2013-02-04, 00:53
Frågan (1) är om/hur en plugin kan påverka GUI:et.
Göra egna fönster från en plugin är nog svårt. Att inom vissa givna ramar lägga till ett menyval eller liknande är däremot ganska lätt.
Frågan (2) är hur plugins ska kunna lagra/skapa/aceessa egna data. Anta att man gör en sök-plugin. När man söker via denna får man ett visst resultat. Hur ska pluginen kunna lagra detta för senare bruk? Ska pluginen alls kunna detta?
tommypeters
2013-02-04, 13:50
Möjligen lagrar man datat i xml-filer där namnet på filen är söknyckeln.
Av vad jag kan läsa i denna tråd får jag intrycket att tilläggsfunktionaliteterna (i form av ex.vis plugin-er) avses exekvera i samma process som Disgen, med alla de risker och problem som det medför. Avsevärt mycket bättre vore, tycker jag, att speca ett protokoll - baserat på TCP eller UDP - via vilket tilläggsprogramvarorna som klient kommunicerar med Disgen (som server).
Fördelar:
Mera portabelt (såväl över OS som implementationsmiljöer),
bättre stabilitet (exekveringsfel i en "plugin" behöver inte påverka Disgen-processen,
så länge protokollet bibehålls kan Disgen och "pluginer" uppdateras oberoende av varandra,
o.s.v.
Finns det ens någon plugin-framework för Delphi som är portabel över Mac, Windows och Linux?
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.