[fria24] Vilken teknik bör användas ?

[Anders Wallenquist]

Anders Lindbäck wrote:

>Anders Wallenquist wrote:
>  
>
>>
>>>>Jag är rädd att Zope kan visa samma tendenser. Se bara på Plone som
>>>>blivit långsam då de lagt till en massa funktionalitet till Zope.
>>>>  
>>>>
>>>>        
>>>>
>>I rätt sammanhang tycker jag att man kan förlåta Zope för dessa
>>tendenser, men man bör anlägga perspektivet färdiga applikationer och
>>välja Zope-plattform när det är den färdiga applikationen som i kraft av
>>att vara bästa alternativet också motiverar Zope.
>>    
>>
>
>
>Du förordar ett lapptäcke av olika webbtjänster skrivan i många olika språk ?
>  
>
Javisst, eftersom jag tror mer på systemintegrationsprojekt än
utvecklings av något helt nytt från scratch. Det finns alltid risk för
Not-Invented-Here-sjukan, styrkan med fri programvara är att kunna hänga
på ett befintligt projekt och addera det som saknas för att en ny
målgrupp skall kunna använda det. Att arbeta med fri programvara är en
del byggandet av användarföreningen och en del att utveckla programvara,
en stark användarförening är förutsättningen för att skapa livslängd på
produkten, utan stark användarförening finns det INGEN kommun eller
statlig förvaltning som vågar (eller borde våga) satsa på systemet. Med
en befintlig användarförening så vågar potentiella användare mönstra på
och bidra med underhåll och vidareutveckling i mer blygsam omfattning.

Tag det färdiga bokningssystemet/workflowsystemet , addera SHS-koppling,
någon Webservices-koppling och några få anpassningar  så att det är ett
dagissystem (eller annan lämplig tillämpning). Kör projektet i knät hos
en lämplig pilotkund.

Ja detta synsätt innebär att det kommer finnas flera programspråk
inblandade i takt med att "färdiga" applikationer välsignas och ansluts
till plattformen Fri 24. Det viktigaste plattformen i sig kan bidra med
är enligt min uppfattning detaljerade riktlinjer och krav på
komponenterna i lösningarna och goda exempel på lösningar som används i
praktiken. Får vi en eller flera piloter som kan visas upp att de
använder Fri 24, sparar tid och pengar genom att använda plattformen,
metoden fri programvara och lyckligare medborgare eftersom det är öppna
standarder rakt igenom.

>För mig känns det som att projektet kommer att fasta i att ingen kommer att
>kunna hela systemet för att det är skrivet i så många olika språk och därför
>blir en mardröm att underhålla.
>  
>
Det är sant i perspektivet traditionell systemutveckling i den slutna
världen. Om detta är målet med projektet är det chanslöst att komma i
mål med frivilliga krafter, chanslöst att skapa legitimitet för framtida
vidareutveckling och underhåll, chanslöst att hitta varken pilot eller
skarpa användare.

>
>  
>
>>>>Jag lägger min röst på Drupal.org, det är en LAMP-lösning, bra och enkel att utveckla i, kan driftas
>>>>av en liten organisation utan erfarenhet av Linux tidigare, går utmärkt att konfigurera med enbart
>>>>fria program på t ex Debian/Ubuntu-plattform. Det finns fina SOA/Webservices-kopplingar, klarar
>>>>ordentlig last, går att lastbalansera, E-handel, CRM, CMS med vattentäta skott mellan innehåll och 
>>>>tema-motor, riktig begreppsapparatmotor med synonymhantering, Ajax-stöd
>>>>för feta klienter - är på alfa-stadium, men kul att ha när det kan vara tillräckligt stabilt för 
>>>>professionella lösningar. Lätt att hitta utvecklare till, bra översättningssystem, stor internationell
>>>>
>>>>        
>>>>
>>>Ja, LAMP är en intressant lösning. Problmet som jag ser det är att det inte
>>>ingår en applikationsserver i LAMP utan allting lagras i en databas och
>>>via webbsidor manipuleras datat i databasen. Som jag ser det så kommer
>>>Fria 24 kräva att det finns en applikationsserver i bakgrunden som gör mycket
>>>av jobbet och då är tyvärr inte LAMP den rätta vägen att gå.
>>>
>>>
>>>      
>>>
>>Om Drupal/PHP pear inte är en applikationsserver så vet jag inte vad en
>>applikationsserver är för något.
>>
>>Förstår inte riktigt resonemanget att det krävs webbsidor för att
>>manipulera data i databasen? Visserligen så är SOA, SOAP, Webservices,
>>XMLRPC med flera protokoll över port 80, webb-porten - om det skulle
>>betyda att det är "webbsidor" som manipulerar data i databasen?
>>    
>>
>
>
>En applikationsserver är en separat server från webbserver som kan
>köras i sin egen hårdvara. För stora system där man tänker på skalbarhet
>så är det ett krav att det hela kan köra på flera fysiska datorer
>för att kunna hantera anstormningen av kunder men även för att hantera
>redundans osv. Zope och Tomcat är exempel på applikationsservrar.
>  
>
Du kan köra en XMLRPC-server, en SOAP-server, en WebDav-server,
FTP-server, SMTP-server, IMAP-server baserat på PHP och Drupal på exakt
samma sätt som du gör i Zope eller Tomcat.

De prestandatester jag gjort med Zope och Tomcat så har PHP sprungit
cirklar kring dessa - så prestanda, möjligheten för redundans och
skalbarhet är ett litet problem i sammanhanget. Det finns andra
parametrar som är viktigare.

Jag skulle vilja att vi i stället tittar på applikationssidan, var
hittar vi kortast väg till en enklast möjlig lösning hos en tänkt pilot,
med största möjliga effekt? Vilka parametrar i den tänkta lösningen
exponerar fördelar med fri 24/fri programvara? Vem är piloten och vilka
parametrar kan attrahera piloten?

Ett tänkbart delprojekt är SHS-anslutning, en server som talar SHS i ena
änden och (kanske) Webservices i andra. För en sådan server är det
overkill att använda en applikationsserver för. Det är bättre att
plattformen för den har så litet footprint som möjligt och kan anslutas
till så många potentiella applikationer som möjligt. Är det inte så att
90 % av lösningarna har behov att kommunicera ett eller flera
meddelanden via SHS? Har någon GPL-kod för SHS-kommunikation?

/Anders W