T!NG, fællesskabet og fremtiden.

Indledning

T!NG er ved at blive voksen.  Verden er ved at blive mobil. Folk har så mange måder at bruge nettet på. For ikke så mange år siden var det nok med en hjemmeside og en database, men ikke mere. Folk ønsker at kunne tilgå alt muligt hele tiden på alle mulige platforme og det samme gælder deres stigende forventninger til bibliotekerne. Men hvordan sikre vi os en lys fremtid?

Problemerne

Ét eksempel ville være alt det arbejde der bliver lagt i ding.T!NG. Ikke fordi der er noget galt med det, men udviklingen sker primært i drupal moduler - hvad med dem som skal bruge umbraco, plone, joomla eller noget helt andet? – det hjælper heller ikke på de mobile platforme hvor der måske bruges PhoneGap, jQuery mobile, Objective-C i Xcode eller noget helt tredje? – Det hjælper heller ikke at mange biblioteker køber sig til forskellige ting og at disse ikke falder ind under Open Source på den ene eller den anden måde så flere af os heller ikke kan drage nytte af det?

 Kort fortalt opfinder vi gerne hver for sig vores dybe tallerken på en måde der gør den svær eller umulig at dele med resten af klassen. Fællesskabet har brug for at udvide sig til at inkludere alle eller i det mindste så mange som muligt. T!NG skal rykke fremad hurtigt og sikkert. Og alle skal med på toget!

En mulig løsning

Jeg læste for ikke så lang tid siden et blog indlæg som fik mig til at tænke. Hvad nu hvis vi udviklede et sæt fælles API’er hvor så meget af den samlede funktionalitet i T!NG projekterne løbende blev lagt over så hver gang nogen bidragede med noget kom det virkeligt alle til gode?  

Hvad nu hvis det kunne virker på alle platform både de nutidige og de fremtidige?  

Utopi siger du nok, men det er faktisk muligt! Jeg siger ikke at folk skal droppe hvad de har i hænderne og bare komme i gang med noget helt nyt … det ville være et sideløbende projekt der har til formål at gøre alt det gode i T!NG tilgængeligt for alle !

Jeg har oceaner af information til alle interesserede og håber på en god og saglig/teknisk debat :)

 

TIA,

Jan Bæch.

Kommentarer

Sjovt nok lyder BAAPs som

Sjovt nok lyder BAAPs som nøjagtigt det samme som jeg gør :p

Nærmere forklaring, tak

For at forstå dig rigtigt, ville det være rart, hvis du kunne komme med en mere konkret forklaring på, hvad du gerne vil ift. hvordan du ser den nuværende situation?

Kan du fx. forklare hvordan visning et søgeresultat, en blogpost og/eller en lånerstatus ud fra dit perspektiv burde fungere hvordan det er nu?

Ja den første del af

Ja den første del af forklaring vil ikke være særligt egnet for ding-folket da den 1 fase består i at stjæle ... *host* ... konvertere så meget som muligt fra de andre projekter til et 'format' der er mere anvendeligt specielt udenfor web, men hele ideen opstod af et behov uden for ding. Så lad mig begynde lidt fra starten og bevæger mig forsigtigt fremad :

Men først en indrømmelse : jeg kan godt lide (e)bøger og i min samling er der blandt andet "Drupal 7 Mobile Web Development Beginner's Guide" og da jeg så den tænkte jeg "Hehe det bliver jo pærelet ... hvis vi bare kan 'omformulere' ding til en mobil version er alt jo løst", men der tog jeg fejl.

Så her er en lille anekdote som måske bedre kan belyse omfanget af mit problem :

En dag for nogen tid siden sad jeg på min plads foran min computer og bandede over hvorfor det skulle være så svært at gå over til windows print i DDELibra da min boss kom ind ... hun vidste efterhånden en del om T!NG og sagde derfor :

"Jan, vi skal have en iPhone App ... og det skal være en RIGTIG app" (med det mente hun en IKKE web eller hybrid app)

og jeg sagde "Nåh ...."

Og så sagde hun "... og vi skal nok også have en til Android og hvad der ellers er !"

og så sagde jeg "Okay ........ " 

Hun var også rimelig klar over at vores nuværende hjemmeside (som er Plone baseret) skulle erstattes af ding.T!NG senere hen !

 

Jeg havde ikke lige set den kommer, men jeg gik igang og fandt hurtigt ud af at jeg behøvede mindst 2 ting : Da vi bruger DDLibra skulle vi have fat i Alma hvilket var fint for jeg kende et par af de udviklere der havde skabte det et sted i det mørke sverige så det skulle nok være nemt nok.

Dernæst skulle jeg bruge brønden og det var så her det begyndte at blive lidt svært ... al brugbar kode var i php og brønden gad ikke arbejde sammen med visual studio så jeg skulle lave det hele selv i hånden ! ... en opgave det skulle vise sig at tage flere måneder !

Og så var det jeg tænkte : Jeg kan da umuligt være den eneste der arbejder på en native app til en eller flere af de nu 3 platformer (iPhone, Android og Windows Phone 7) og hvis jeg alligevel er nød til at lave det hele selv kan andre ligeså godt få nytte af det og måske hjælpe mig lidt også (som sagt er jeg IKKE noget geni).

Jeg kunne fortsætte mange sider endnu, men for ikke at kede dig går projektet i sin enkelthed ud på følgende :

Der udarbejdes en API (jeg har indtil videre samlet det hele i en fil ved navn "TING.dll" men om det er smart at samle det hele her er ukendt !) som kan inkluderes i projekter til alle tre platforme og også web selvom jeg ikke må (plus stort set alle andre). APIen skal indehold al den funktionalitet man kunne ønske sig i forbindelse med T!NG projketet. Dette gælder også de ting du har nævnt: lånestatus, søgning osv. 

Fordelen er at måske 80% af koden kan genbruges; kun GUI skal laves til hver platform.

 

Et kode eksempel (som her er i c# som jeg foretrækker) ville være noget i denne stil som er en stress-test jeg kørte for sjov der henter 300000 post fra brønden og dumper posterne (50 af gangen) til consol vinduet ... jeg har blot bedt om at søge på 'a' i CQL da det sikre jeg har poster nok ... :

 

using System;
using TING.OpenSearch;
using System.Xml.Linq;


namespace Testing
{
	class MainClass
	{
		public static void Main (string[] args)
		{
			OpenSearch os = new OpenSearch();
			
			int i = 1;
			while(i < 300000)
			{
				os.search("a", _start: i,_stepValue: 50 );
				Console.WriteLine("Done - i = " + i.ToString());
                                Console.WriteLine(os.result);
				i += 50;	
			}
			Console.WriteLine();
			Console.WriteLine("Finish");
			Console.ReadLine();
		}
	}
}

Koden er ekstrem simpel, men pointen er at den kan genbruges uændret på alle platforme, dvs. man skal ikke kunne Objectiv-C, java eller hvad det nu er. Det er ikke vigtigt at du forstår koden, men at du ved at den faktisk virker !

Så forskellen fra i dag ville være at også ikke-drupal folkene mere kan være med på lige fod med alle andre :)

Håber det hjælper dig :)

API = DLL?

Der udarbejdes en API (jeg har indtil videre samlet det hele i en fil ved navn "TING.dll" men om det er smart at samle det hele her er ukendt !) som kan inkluderes i projekter til alle tre platforme og også web selvom jeg ikke må (plus stort set alle andre).

Kan du forklare nærmere hvordan en DLL-fil skulle være brugbar på alle platforme?

Nu arbejder jeg jeg selv primært i PHP, og her er det ikke standard praksis at benytte DLL filer. Lidt hurtig søgning siger at det langtfra er alle DLL-filer der overhovedet kan bruges. Min umiddelbare fordom er at det også vil være problematisk i andre sprog, der afvikles fra en ikke-Microsoft server.

DDB - CMS

Der er sådan set ikke noget hemmeligt i hvad DDB pønser på.

Det CMS som vi påtænker at tilbyde vil være baseret på ding2tal, med nogenlunder samme principper som der allerede findes. Som der også er blevet udmeldt, så vil hele DDBs infrastruktur basere sig på alt det gode arbejde der allerede er udført i T!NG. Ingen grunde til at udvikle det hele på ny igen.

Når jeg læser blogindlægget samt kommentarerne så undrer det mig at der efterspørges flere APIer, da stort set alt hovedfunktionalitet i ding.TING findes i et API lag. Her snakker vi søgning, bibliotekssystemtransaktioner (reservering, fornyelser, betaling etc.), forsider, ADHL plus lidt mere. Alt sammen dokumenteret her http://ting.dk/wiki/chapter-2-architecture

Åbn billedet i en ny fane for at se det hele, da mit billede i Chrome gemmer sig bag boksene i højre side.

Så er der projeker i gang allerede nu som BAPPS, Biblioteksproduceret Indhold, Personalisering og WAYF som fjerner endnu mere funktionalitet fra Drupal, men kun der hvor man ser en rationaliseringsgevinst. Allesammen projekter støttet af Kulturstyrelsen.

Så kunne man i teorien lave endnu et API til de resterende funktionaliteter som oprettelse af virkelig lokalt indhold, kommentarer, navigation mm. Altså alt den almindelige CMS del, men omend det er en smuk teori, så vil det øge udviklingsomkostningerne for alle, til fordel for de biblioteker der ikke kan eller vil bruge Drupal.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.