X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/a93d61e1567d5836402fdadf90f5380108df5d0b..3882048f60f47ce7edb89cc3816978cff32551f9:/blog/data/2009-02-18-protokoll-og-format.txt diff --git a/blog/data/2009-02-18-protokoll-og-format.txt b/blog/data/2009-02-18-protokoll-og-format.txt index 8441553234..8601d58d32 100644 --- a/blog/data/2009-02-18-protokoll-og-format.txt +++ b/blog/data/2009-02-18-protokoll-og-format.txt @@ -1,25 +1,30 @@ Title: Standardize on protocols and formats, not vendors and applications -Tags: english -Date: 2009-02-18 11:50 -Publish: 2010-01-01 +Tags: english, nuug, standard, debian +Date: 2009-03-30 11:50 +Publish: 2009-03-30 -Where I work, one of the decisions +

Where I work at the University of Oslo, one decision stand out as a +very good one to form a long lived computer infrastructure. It is the +simple one, lost by many in todays computer industry: Standardize on +open network protocols and open exchange/storage formats, not applications. +Applications come and go, while protocols and files tend to stay, and +thus one want to make it easy to change application and vendor, while +avoiding conversion costs and locking users to a specific platform or +application.

- - on network protocols and exchange formats - - open standards is a clear advantage - - give support on applications - - allow other apps - - allow us to change clients and keep the servers, or replace the - servers and keep the clients +

This approach make it possible to replace the client applications +independently of the server applications. One can even allow users to +use several different applications as long as they handle the selected +protocol and format. In the normal case, only one client application +is recommended and users only get help if they choose to use this +application, but those that want to deviate from the easy path are not +blocked from doing so.

- - smtp - - imap - - nfs - - ldap - - ntp - - X11 - - syslog - - ODF - - text - - html - - rst +

It also allow us to replace the server side without forcing the +users to replace their applications, and thus allow us to select the +best server implementation at any moment, when scale and resouce +requirements change.

+ +

I strongly recommend standardizing - on open network protocols and +open formats, but I would never recommend standardizing on a single +application that do not use open network protocol or open formats.