Hoofdcategorieën
Device Settings

Microsoft geeft documentatie pst-bestandsformaat vrij

Door Wilbert de Vries, dinsdag 27 oktober 2009 09:26
Submitter: TimeVortex, views: 19.577

Microsoft heeft deze week bekendgemaakt documentatie over zijn pst-bestandsformaat, dat wordt gebruikt om Outlook-data als mail en contacten op te slaan, vrij te geven. De documentatie wordt vrijgegeven onder Microsofts OSP.

Hoewel Microsoft voornemens is de documentatie te openbaren, heeft de softwaremaker zichzelf geen deadline gesteld wanneer dit moet zijn gebeurd. Wel benadert de fabrikant momenteel geïnteresseerde klanten en industrie-experts om feedback te krijgen op zijn plannen. Microsoft wil onder meer weten hoe technisch de documentatie moet zijn, meldt Ars Technica.

Als Microsoft de documentatie gereed heeft, zal het worden vrijgegeven onder de Open Specification Promise, een Microsoft-programma dat ontwikkelaars vrijwaart van juridische vervolging als zij specificaties gebruiken die onder OSP zijn vrijgegeven. De technische informatie zou in detail moeten uitwijzen hoe informatie is opgeslagen en hoe deze data vanuit andere applicaties kan worden benaderd.

Met behulp van de documentatie zouden ontwikkelaars dus gegevens uit pst-bestanden moeten kunnen lezen of er juist naartoe wegschrijven zonder juridische consequenties. Pst zou hierdoor in theorie als breder gebruikt bestandsformaat gebruikt kunnen gaan worden, ongeacht het platform of programmeertaal.
Volgende 09:54 Video Assassin's Creed II
Vorige 08:49 'Nieuwe MacBook Pro's met Core i7 en Radeon-gpu op komst'
Advertentie

Reacties

«  1  2  »

Pst zou hierdoor in theorie als breder gebruikt bestandsformaat gebruikt kunnen gaan worden, ongeacht het platform of programmeertaal.
PST is nou niet bepaald legendarisch op het gebied van performance en betrouwbaarheid... Ik weet niet of de wereld hier wel op zit te wachten.

Het is in ieder geval een enorme winst als je een ander mailprogramma gaat gebruiken die de PST-bestanden probleemloos kan inlezen en omzetten. :9

Ik denk dat het met de documentatie makkelijker wordt om PST te importeren naar een ander mail programma die een betrouwbaarder formaat gebruikt :P

Dit kun je ook doen met de beschikbare API. Beschikking over het PST is wel nodig indien je naar een ander platform gaat, of indien je de API wil uitbreiden.

Het is dus winst, als tot op het kleinste detail-niveau de technische documentatie wordt vrijgegeven.

Dit kun je ook doen met de beschikbare API.
Daar heb je niks aan als je geen (werkende) Outlook hebt op het systeem.

Vandaar dat ik zei dat het bekend gemaakte bestandsformaat als toevoeging handig is.

Wel als je op een Mac werkt, want zelfs Microsoft Entourage kan niet overweg met .pst-bestanden!

Lol.. dat is een gemis :)

Vaag hoor... vooral als je je bedenkt dat het beiden van MS is.
Btw nooit gesnapt waarom niet alles hetzelfde heet:

Word 2007 (win) --> Word 2008 (mac)
Excel .....

En dan is het alternatief voor Outlook ineens Entourage. :S

Waarschijnlijk omdat Outlook allerlei systeem-DLL's (mis)bruikt en dus niet makkelijk te porten valt.

Lijkt mij dat MS de code van die Windows-systeem-dll's wel heeft en dit dan kan gebruiken...
Ik denk eerder dat MS de Mac als een bedreiging ziet voor bedrijfsomgevingen. Zolang ze geen Outlook ondersteuning bieden in het Office pakket wordt de Mac als minder handig gezien in bedrijfsoplossingen met Exchange voor mail en agenda. Nu Apple in 10.6 Exchange volledig ondersteund in Mail en iCal, zie je dat MS ook meegaat in Office, omdat anders mensen geen Office meer nodig hebben...

Mac en Windows hebben een verschillende doelgroep en gebruikersinterface. Het is niet zo vreemd dat een fabrikant verschillende versies uitbrengt om een goede aansluiting op het OS te kunnen bieden.

Maar dat rechtvaardigt niet dat .pst-bestanden op een Mac niet herkend worden door Entourage. Ik vermoed dat Microsoft dat uit concurrentieoverwegingen zo doet.

En dan is het alternatief voor Outlook ineens Entourage
Gelukkig gaat het vanaf de volgende Office for Mac-versie weer wel gewoon Outlook heten, aldus Microsoft zelf.

misschien dat er nu meer programma's komen die PST bestanden kunnen repareren als er iets mis gegaan is :P het meegeleverde softwarestukkie doet niet altijd zn best :P

Als je goed met je pst bestanden omgaat en je gebruikers dit ook leert hoef je geen pst bestanden te repareren ;)

Kom nou. Het zou niet nodig moeten zijn om je gebruikers te trainen hoe ze met een bestand moeten omgaan dat door hun mailclient achter de schermen wordt gebruikt.

Het is in de eerste plaats natuurlijk bezopen dat een applicatie z'n data bestanden zelf aan gort kan trekken... een bedrijfskritisch systeem zoals email moet gewoon robuust werken...

Dan kunnen je gebruikers ook niks fout doen.. regel 1 in systeembeheer: bescherm de gebruiker voor z'n eigen dommigheid.

[Reactie gewijzigd door cappie op dinsdag 27 oktober 2009 10:43]


In een bedrijf word meestal dan ook met Exchange werkt, en die slaat zijn dat niet in een PST op, maar in een EDB-file (Embedded Database) op de server.

Een PST-file moet je gewoon zoveel mogelijk zien te verrmijden eigenlijk. Het is inderdaad niet het meest stabiele bestandsformaat wat ooi bestaan heeft.

PST heb je wel mee te maken als je moet archieveren (wat je wel moet als je een restricitie hebt op de grote van je mailbox)...

Daarnaast wordt er normaal gesproken alsnog een normaal .pst bestand aangemaakt. EDB is volgens mij ook meer bedoelt als backup/sync mogelijkheid, dan als het werkelijke werkbestand.

[Reactie gewijzigd door MicGlou op dinsdag 27 oktober 2009 11:48]


Nee, EDB is absoluut niet bedoelt als backup/sync mogelijkheid, maar echt als werkbestand.

Maar een mailbox van 500MB is niet voldoende om je archief in op te slaan.
Daar gebruiken mensen dan meestal een PST voor.

Maar PST files zijn in een enterprise omgeving inderdaad bronnen van problemen. Vandaar dat wij het onmogelijk hebben gemaakt om PST files te gebruiken, en een 3rd party oplossing hebben voor de lange termijn archivering.

Ik zeg het misschien wat kort, maar EDB wordt praktisch niet ingezet voor gebruik op een workstation, dan functioneert het mijn inziens toch nog altijd meer als een backup database, immers wordt persoonlijke archivering etc in het PST bestand gedaan. Volgens mij is het ook nog zo dat EDB ook meer is toegespits met gebruik van mobile devices e.d.

Bij de meeste bedrijven heb je een nogal lage limiet op de mailbox. Om je mail te archiveren moet je dan wel met PST werken.

als je met pst's van enkele GB's knoeit, dan vind ik dat de user wel eens met z'n neus op de feiten gedrukt mag worden

Helaas hebben sommige gebruikers de neiging om werkelijk alle mail die ze ooit gehad hebben te bewaren. En ja, dan krijg je PST-files van gigabytes groot ja. Zeker omdat nu met Outlook 2007 de maximumgrootte is verhoogd van 4 GB naar 20 GB per stuk.

Echt, bij vorige werkgevers heb vele gebruikers gezien met GB's aan PST-file op hun homefolder. De grootste die ik tot nu toe ben tegengekomen was 55 GB (in verschillende PST's). Die man had ál zijn mail sinds 1999 bewaard... met attachments en al.

[Reactie gewijzigd door wildhagen op dinsdag 27 oktober 2009 10:47]


Gek he, als je als bedrijf tot 7 jaar terug al je zakelijke e-mail moet bewaren van de Belastingdienst. Zelf heb ik ook al m'n mail nog van tot voor de eeuw-wisseling, wat is daar mis mee? Moet kunnen toch?

Die bewaarplicht van 7 jaar geld alleen voor mail die relevant is voor de bedrijfsvoering, niet voor mails uit de categorie 'mooie vakantiefoto''s, uitnodigingen voor borrels/recepties, en leuke filmpjes van collega's' (want ook die stonden erin).

Daarnaast heb je dit soort belangrijke mails centraal in een backup-archief staan, niet in losse PST-files bij elke gebruiker.

[Reactie gewijzigd door wildhagen op dinsdag 27 oktober 2009 11:06]


Maar het moet kunnen toch? Was de reactie van man-o-script. Ik ben het met hem eens. Er zijn allerlei redenen denkbaar waarom iemand zijn emails wil bewaren. Ikzelf doe dat ook, maar ik bewaar ze in een IMAP-folder op de mailserver, omdat die onder mijn eigen beheer staat. Echter zou dat niet zo zijn, dan zou ik ook met een storage op de computer werken.

En dan heb je als gewone gebruiker met Outlook op het werkstation niet veel keus als pst.

Als gebruiker zonder Outline kun je ook een offline storage instellen, bijvoorbeeld Thunderbird kan dat ook.

Wat is daar het probleem? Juist, de mailclient.
Als hij niet met grote bestanden overweg kan.....dan moet ie het in kleinere bestanden opslaan? (of zou dat te logisch zijn?)

Het formaat dat op (sommige) unix varianten word gebruikt vind ik wel iets hebben....gewoon de rauwe mails opslaan per stuk.
Erg makkelijk als er iets mis zou gaan....1 mailtje mogelijk stuk, de rest doet het altijd.
Misschien kost het iets meer ruimte....maar het werkt

Ik heb al mijn mail die ik sinds eind 2007 (toen ik hier als systeembeheerder in dienst kwam) bewaard. Dit is nu ongeveer 8GB. De reden dat ik dit bewaar, is omdat er handleidingen tussen zitten van enkele software pakketten, licentie overeenkomsten etc etc.

en ik kijk regelmatig naar dat soort documenten. Waarom zou ik het uitprinten als ik het digitaal heb? Daarnaast is het handig om je mail te bewaren, want sommige gebruikers beweren dan iets wat ik nooit gemailed heb, of verdraaien het (mens-eigen denk ik). Ik kan ze dan al mijn mails naar hun laten zien als dat echt nodig is (tot nu toe 2 keer voorgekomen, maar toch).

Ze hangen alleen niet standaard in outlook, maar staan op een externe harde schijf, en ik heb een kopie per jaar die apart liggen.

Sommige mensen (zoals ik) vinden het heel erg fijn dat data bewaard word. Ik hoef het niet op een netwerkschijf te plaatsen (daar heb ik totaal 25MB staan), ik maak de kopie zelf wel.

[Reactie gewijzigd door ArawnofAnnwn op dinsdag 27 oktober 2009 11:10]


55GB over zo'n lange periode is helemaal niet zoveel, ligt er denk ik erg aan wat voor een werk je doet. Ik werk net iets meer dan 2 jaar bij mijn huidige werkgever en moest onlangs verplicht opschonen omdat ik ook al aan de 50GB 'grens' zat. Dan hebben we het nog niet over de mailboxen van onze CAD-ers en grafisch ontwerpers ;) Overigens helemaal niet zo'n slechte oplossing, het alternatief wat de meeste mensen doen is al die mailtjes printen en in een map stoppen, dan is het digitaal beheren toch wel de meer gewenste methode toch?

Die attachments zijn natuurlijk de echte ruimtevreters. Binnen veel bedrijven is het heel gewoon om als volgt te communiceren: een e-mail zonder body, maar met een Powerpoint presentatie van 4 MB eraan met daarin een 8-tal korte punten met een mooi plaatje als achtergrond.

Mijn eerste gebruik van e-mail was op Fidonet, en daar keek je wel link uit om 'grote' berichten te maken als je dat vervolgens met een 14K4 modem moest gaan versturen.

Tegenwoordig is iedereen zo gewend aan breedband dat je je er nauwelijks meer bewust van bent welke enorme hoeveelheden data je verstuurd om relatief weinig informatie door te geven.

Mail als archief werkt eigenlijk heel erg slecht, ik heb tenminste de zoek-functionaliteit van Outlook (2003) nooit echt kunnen gebruiken. Zeker als de 'echte' informatie niet in de e-mail staat maar in de attachment moet je al andere dingen gaan gebruiken om de boel wel te kunnen doorzoeken.

om in outlook te zoekn gebruik in Xobni Plus, werkt prima. Je kunt dan meteen de Windows indexer vertellen dat Outlook niet meer ge-indexed hoeft te worden, scheelt weer tijd.

Ik heb mail op m'n eigen server gelimiteerd tot berichten van een MB of 5 a 10 (weet niet meer exact waar ik m op heb gezet). Als verzenders dan hun bericht weer terug krijgen met de melding dat het te groot is, laten ze het volgende keer wel uit hun hoofd om idioot grote mails te versturen. Email is nooit bedoelt geweest voor grote verzendingen :/

Zeker omdat nu met Outlook 2007 de maximumgrootte is verhoogd van 4 GB naar 20 GB per stuk.
Met Outlook 2003 was dat al hoor. Outlook XP (2002) en lager was de maximum grootte van de PST nog 2 GB en met Outlook 2003 is dat verhoogd naar 20 GB.

Ik snap anders wel waarom mensen al hun emails met attachments bewaren...

Op die manier is hun data namelijk perfect gearchiveerd, en super makkelijk terug te vinden. Ze kunnen niet alleen makkelijk zoeken, maar hebben ook in de bijbehorende email ook nog wat extra commentaar bij de documenten staan.

Wat je hier eigenlijk ziet, is dat Outlook een behoefte opvult wat betreft metadata bij bestanden. Dat werkt weliswaar niet perfect, maar wel veeel beter dan de bestanden kaal op een folder op de harddisk opslaan.

Als een applicatie tussen de .pst en de gebruiker zit (net zoals MySQL/InnoDB tussen een of andere ibdata1 file en de gebruiker zit), moet de applicatie dat ondervangen. Bijvoorbeeld uit zichzelf de bestanden binnen proporties houden of dingen niet toestaan.

Blijkbaar is .pst de MyISAM onder de mail-opslagformaten :P

Zelf heb ik ook gigantisch veel e-mail, maar dan wel op een IMAP-server in Maildir formaat + Dovecot indexes op een transactioneel bestandssysteem. Nooit meegemaakt dat iets kapot ging.

[Reactie gewijzigd door Sfynx op dinsdag 27 oktober 2009 17:51]


Mooi nieuws natuurlijk, meer openheid is altijd welkom. Toch verbaast het me dat dit nu pas komt, als je nagaat hoeveel PST-repareer programmatjes er al uit zijn (waarbij ik gemakshalve even vergeet dat de helft niet- of amper werkt). Sowieso zijn er al heel wat Microsoft formaten openbaar, ik zat laatst de specificaties van .doc bestanden (dus niet de .docx formaten) te bekijken. Met de overstap naar .docx, wat meer XML-based is, hebben ze het zichzelf dan toch heel wat gemakkelijker gemaakt.

Het libpst project zet zich al een hele tijd in voor documentatie van het bestandstype, zo te zien met name door Reverse Engineering.

Met .docx hebben ze het wiel opnieuw uitgevonden om concurrentie te hinderen. Er bestond al een goede open (ISO) standaard, voor Office documenten gebaseerd op XML. En Microsoft moest toch weer hun eigen standaard uitvinden en er op twijfelachtige wijze doorheen drukken.

Zelf zit ik meer te wachten op documentatie van het .mdb-formaat zoals gebruikt in MS Access. Op dit moment is het ongmogelijk om dat op een ander besturingsysteem dan Windows te lezen. De andere formaten waren al lang voordat de documentatie werd vrijgegeven doormiddel van reverse-engineering toegankelijk, maar dit bestandsformaat niet.

Dat ben ik niet geheel met je eens. Ondanks dat het natuurlijk zo is dat het introduceren van een nieuw bestandstypes ook nadelen met zich meebrengt, met name op het gebied van compatibiliteit, is het ook voor Microsoft zelf een enorme sprong vanaf het oude doc formaat. Het nieuwere .docx formaat is een ECMA-376 standaard, ook wel bekend als het Office Open XML dat gebruikt wordt vanaf Microsoft Office 2007. Dit formaat is tevens een ISO standaard en uitgebreid gedocumenteerd, dus ook toe te passen voor andere bedrijven en programma's die daar interesse naar hebben.

Verder is er een documentatie van mdb bestanden beschikbaar op deze pagina. Wel zul je goed met C/C++ of een andere programmeertaal aan de gang moeten om er iets mee te doen, maar dat zal bij ieder bestandsformaat zo zijn (op XML na, door de vele beschikbare libraries).

is het ook voor Microsoft zelf een enorme sprong vanaf het oude doc formaat. Het nieuwere .docx formaat is een ECMA-376 standaard, ook wel bekend als het Office Open XML dat gebruikt wordt vanaf Microsoft Office 2007.
Alleen is het Office Open XML [OOX] formaat weer wel sterk gebaseerd op het oude binaire formaat. En dat geeft Microsoft natuurlijk weer wel een voordeel.

Twee voorbeelden:
  1. Er wordt, in de OOX-standaard gerefereerd aan VML een MS-only markup taal.
  2. De standaard bevat willens en wetens referenties aan applicatie-specifieke implementaties (renders as Word 'XX bijvoorbeeld).
N.B. Mogelijk dat sommige van dit soort zaken reeds verwijderd zijn, maar ze had nooit in een ECMA-document mogen staan...
Dit formaat is tevens een ISO standaard en uitgebreid gedocumenteerd, dus ook toe te passen voor andere bedrijven en programma's die daar interesse naar hebben.
Op zich wel, alleen is het dan wel jammer dat de 'standaard' de (ongeschreven) regels die voor XML-documenten gelden schend - denk o.a. aan het human-readable zijn van de XML-serialisatie...

Alleen is het Office Open XML [OOX] formaat weer wel sterk gebaseerd op het oude binaire formaat. En dat geeft Microsoft natuurlijk weer wel een voordeel.
Een belangrijk doel van Office Open XML is het bieden van compatibiliteit met de oude binaire formaten. Dat betekent logische overeenkomsten (bijvoorbeeld in document structuur en ondersteuning van de features).
Er wordt, in de OOX-standaard gerefereerd aan VML een MS-only markup taal.
VML is een markup taal waarvan de specificaties door MS al 12 jaar geleden bij W3C zijn ingediend en als zodanig zijn de specificaties daarvan altijd al bekend. VML wordt bijvoorbeeld ook gebruikt door Google maps. Verder wordt er in de Office Open XML standaard niet aan dit formaat gerefereerd maar is de hele specificatie opgenomen en dus als standaard vastgelegd. (in het transitional gedeelte dus strict OOXML bevat geen VML)
De standaard bevat willens en wetens referenties aan applicatie-specifieke implementaties (renders as Word 'XX bijvoorbeeld).
Daarmee wordt het mogelijk om oude geconverteerde documenten heel precies te reproduceren. Omdat deze settings zijn gedefinieerd zijn ze volledig interoperabel tussen applicaties. Deze settings zijn ook transitional.

Overigens heb je bijvoorbeeld ODF bevat een vergelijkbaar mechnisme maar dan met willkeurige ongedefinieerde settings. In OOo heb je bijvoorbeeld settings vergelijkbaar met "renders als vorige versie". Deze ODF settings zijn ongedefinieerd en daardoor juist niet interoperabel. Je kunt dus nooit ODF bestanden volledig interoperabel maken die deze settings gebruiken terwijl OOXML bestanden juist wel interoperabel zijn.
Op zich wel, alleen is het dan wel jammer dat de 'standaard' de (ongeschreven) regels die voor XML-documenten gelden schend - denk o.a. aan het human-readable zijn van de XML-serialisatie...
Dat is ook niet waar. OOXML ongeveer net zo human readable als ODF. Het maakt echt weinig uit of je bijvoorbeeld </p> of </paragraph> gebruikt voor leesbaarheid.

[Reactie gewijzigd door hAl op dinsdag 27 oktober 2009 10:53]


Een belangrijk doel van Office Open XML is het bieden van compatibiliteit met de oude binaire formaten. Dat betekent logische overeenkomsten (bijvoorbeeld in document structuur en ondersteuning van de features).
Jammer dat men zich bij ontwerpen van een geheel nieuw bestandsformaat niet heeft laten leiden door logische requirements maar vanuit compatibiliteit van juist datgene wat al vijftien jaar om compatibiliteits-reden wordt meegezeuld.
Er zijn vele manieren om features te ondersteunen.

Het had echt anders gekund. Een gemiste kans.

Voor de rest lijkt mij de ODF <-> OOXML oorlog te off topic om hier op in te gaan.

[Reactie gewijzigd door SimonKroller op dinsdag 27 oktober 2009 11:41]


De meest logische requirement is juist het compatible zijn met het meest gebruikte en populaire document formaat dat er is. Daarin is namelijk al gigintisch veel kapitaal geinvesteerd. Het is juist ODF waarbij het volstrekt onduidelijk is wat daaraan voor logische requirement daaraan ten grondslag ligt. Het is dus minder compatible, minder featurerijk en het is ook niet erg interoperabel.

Door die slechte compatibiliteit is ODF ook erg slecht bruikbaar als opvolger voor de binaire documentformaten omdat veel applicaties die nu binaire bestanden produeren niet makkelijk ODF kunnen implementeren. Het ondersteunt minder features en er is geen goede documentatie en er is nauwelijk goede tooling (API's).

Verder weet iedereen jaren dat het enomr vertraagde ODF 1.2 er aan komt en dat alle huidige ODF applicaties dan weer enorm (zeker voor spreadsheets) op de schop gaan. Ook geen positieve zaak.

Het is juist ODF waarbij het volstrekt onduidelijk is wat daaraan voor logische requirement daaraan ten grondslag ligt.
Ik snap niet zo goed waarom je ODF hierbij sleept? Kun je niet over OOXML schrijven zonder een ander formaat erbij te halen? Het lijkt zo OS-war-achtig waar veel fora mee vervuild worden.

Microsoft en haar fans tegen de rest van de wereld

Maar goed, schijnt zo te moeten, voor mij is die discussie dan minder interessant.

[Reactie gewijzigd door SimonKroller op dinsdag 27 oktober 2009 12:18]


Laat hAl toch lekker in z'n fanboy-soep gaarkoken... Hij is een van de grootste MS fanboys die hier rondloopt en kan geen kritiek op MS aanzien, en gaat daarom maar een beetje ODF lopen flamen zonder bronvermelding. Dat doet ie altijd en dus ook hier weer.
Eigenlijk maakt ie alleen zichzelf maar belachelijk door dingen te roepen als "ODF heeft slechte compatibiliteit", terwijl iedere andere fabrikant van kantoorsoftware al ODF ondersteund.
"Ondersteund minder features"? Kom op zeg, features als "renders like MS Word 97" heeft niemand nodig...
"Bij ODF is er geen logische grondslag"? Wtf, zelfs een koe blaat nog zinniger dingen. Zo heb ik er ook nog een voor je: Bij MS is er altijd een logische grondslag voor beslissingen en dat is hun missie om de vendor lock-in zo groot mogelijk te houden.
Als er een 1.2 versie aankomt, zal dat ongetwijfeld compatible zijn met vorige versie. In ieder geval een stuk meer compatible dan dat onderlinge MS Office versies dat zijn, dus waarom het geen positieve zaak zou zijn...?
<flame>Voor OOXML is er overigens ook geen goede tooling, alleen maar MS apps, en MS apps zijn toch rotzooi.</flame>

Als je nog een keer complete bullshit loopt te posten, doe er dan een bronvermelding bij, in plaats de reacties te vervuilen met willekeurige rare hersenkronkels van een MS fanboy.

En ik meld alvast maar van tevoren dat hAl hier ongetwijfeld een reactie op zal posten, en ik er niet op inga, ik heb geen zin meer in z'n vervelende geflame altijd...

Op dit moment is het ongmogelijk om dat [mdb bestanden] op een ander besturingsysteem dan Windows te lezen
mdbtools anyone? ;)

Wordt o.a. gebruikt door Kexi, zie bijvoorbeeld de Northwind database geimporteerd vanaf Access.

Met .docx hebben ze het wiel opnieuw uitgevonden om concurrentie te hinderen. Er bestond al een goede open (ISO) standaard, voor Office documenten gebaseerd op XML
Met de docx files hebben ze niet opnieuw het wiel uitgevonden. Microsoft ontwikkelde hun XML format al vanaf 1998 en gebruikte al een XML format in MS Office vanaf MS Office 2003. Office Open XML (o.a. docx files) is een ISO/IEC standaard ontwikkeld uit de interne opvolger daarvan. Je kunt ook nog delen van de markup van de MS Office 2003 files terugvinden in de Office Open XML markup.

En ODF was volstrekt niet een goede standaard maar een vooral een erg incompleet stel specs die alleen implementeerbaar zijn door OOo source code te gebruiken. Misschien dat ODF eindelijk wat wordt met versie 1.2 waar nu al 3 jaar aan gewerkt wordt.

Laten we het alsjeblieft niet meer hebben over ISO. De waarde van een ISO standaard is nagenoeg nul sinds MS besloot de organisatie te mollen voor een eigen doeleinden.

Gek he dat de marktleider zich niet door Open office een bestandsformaat laat opleggen!

Verklaar je nader?

Zoals jij het zegt lijkt het alsof bij Microsoft marktpositie een beweegreden is om een ISO standaard links te laten liggen.

Dat is een interessante visie, die ik nog nergens bevestigd heb gezien.

Welke redenen heb jij om aan te nemen dat dit zo is?

[Reactie gewijzigd door SimonKroller op dinsdag 27 oktober 2009 12:19]


Uiteraard is dat een reden.

als je een kleine speler bent, dan is het belangrijk dat je zoveel mogelijk andere formaten ondersteunt, omdat gebruikers anders geen goed gebruik kunnen maken van je software.

Als je de marktleider bent met een zeer grote voorsprong op de rest, en dus de de-factor standaard, dan hoef je je niet druk te maken over andere kleine standaardjes die vrijwel niet gebruikt worden.

Dan hoef je je alleen druk te maken over de functionaliteit die jij zelf in je standaard nodig hebt.

Als een bestaande of nieuwe standaard niet voldoende functionaliteit biedt, dan maak je gewoon je eigen standaard.

Vrijwel alle succesvolle standaarden zijn gemaakt door monopolisten of zeer grote marktleiders.

Vrijwel alle succesvolle standaarden zijn gemaakt door monopolisten of zeer grote marktleiders.
Veel succesvolle standaarden zijn gemaakt door samenwerkingsverbanden uit de industrie, regelmatig zijn ook universiteiten en maatschappelijke organisaties betrokken.

Hoe meer partijen betrokken zijn, hoe meer kans op succes voor een standaard.

(een heel ander beeld dan jij oproept)

[Reactie gewijzigd door SimonKroller op dinsdag 27 oktober 2009 13:05]


Van de oude bestandsformaten doc, xls enzo was al veel te veel bekent bij concurrenten. Als vendor-lock-in werkte dat niet meer goed genoeg. Daarom hebben ze de OO XML standaarden bedacht. Daarin zitten dan weer onhebbelijkheidjes in zoals
De standaard bevat willens en wetens referenties aan applicatie-specifieke implementaties (renders as Word 'XX bijvoorbeeld).
zoals Little Penguin hierboven vermeld

die concurrenten dan weer opnieuw moeten interpreteren.

[Reactie gewijzigd door BeosBeing op dinsdag 27 oktober 2009 14:29]


Zou er dan een methode komen om met Rsync wél netjes een pst te syncen?

Ik ben geen voorstander van al je mails in 1 bestand weg te schrijven. Geraakt het bestand corrupt dan ben je alles kwijt, het zal niet de eerste keer zijn.

Ik werk op mac en daar heeft Entourage ook de vervelende eigenschap van alle mails in grote files te bewaren. Met als gevolg dat mijn 10gig mailbox elke uur door timemachine wordt geupdate! Zo krijg je timemachine op 1 of 2 dagen wel vol! Maar de nieuwe Entourage (of outlook) zou ook losse files gaan ondersteunen zoals MAIL doet.

Weet niet precies wat je bedoelt met losse files. Outlook 2007 heeft namelijk ook gewoon de mogelijkheid meerdere files te gebruiken. Ik heb zelf per email adres een datafile.

Met losse files bedoelt hij gewoon per mail een bestand. Als er dan een bestand corrupt raakt ben je hooguit één mail kwijt en niet alles tegelijk.

Hij doelt op het feit dat meerdere mails in één enkel bestand opgeslagen worden, in tegenstelling tot bijvoorbeeld het Maildir formaat waarin elke mail één bestand is.

Dit kan efficiënt worden gebackupped, is simpel genoeg om met de hand te repareren en een corrupt bestand kost je slechts één mailtje. Er zijn natuurlijk ook nadelen aan, zoals verlies van ruimte door de cluster grootte van je filesystem, en slechte performance bij grote aantallen e-mail (ook afhankelijk van het filesystem).

[Reactie gewijzigd door Yggdrasil op dinsdag 27 oktober 2009 10:44]


Efficient backuppen van losse bestanden van een paar kb groot? Ik heb nog nooit een backup pakket gezien die dat efficient kan.
Als een director moet backuppen met 9000 kleine bestandjes of met 1 groot bestand van 2gb groot, weet ik wel welke van de 2 er eerder klaar is.

Het enige waar losse bestanden efficient voor zijn is voor het restoren, niet voor het backuppen :)

en dan is 9000 bestandjes nog maar een kleine mailbox.

50.000 tot 100.000 mails, is bij ons heel normaal.

Een incrementele backup is wel véél makkelijker bij losse bestanden. Anders moet je een binary diff doen met dat ene grote bestand, en dan weet ik nog zo net niet wie er eerder klaar is.

- Het complete idee achter een backup is, dat je er mogelijk zaken uit wilt kunnen restoren, en niet dagen lang in je backup moet zoeken om dat ene mailtje terug te vinden die je per ongeluk gedelete hebt.

- Voor een efficiente tool die kleine bestanden backupt moet je misschien eens kijken naar tar, wat al vele tientallen jaren dienst doet als uitstekend backup programma. Oh wacht, het ging hier over MS, die hebben geen handige commandline tools, alleen maar ingewikkelde gui onzin :+

- Het backuppen van losse bestanden is veel efficienter, want een hoop backup tools kijken of een bestand verandert is bij het maken van een volgende backup, zodat ze ongewijzigde bestanden niet hoeven te backuppen. Aangezien je gigabytes grote bestand altijd verandert, wordt het iedere keer in z'n geheel gebackupt (aangezien het formaat toch niet goed te lezen is door 3rd party tools), in plaats van een paar kb als er 1 nieuw mailtje binnen is gekomen.

Losse bestanden hebben ook genoeg nadelen. Het inlezen van veel losse bestanden gaat (iig op klassieke harddisks) een stuk langzamer. Daarnaast nemen deze meer ruimte in beslag (door de cluster grootte).

Boeien. Ruimte zat en als je mails zo groot zijn dat ze niet snel genoeg worden ingelezen dan heb je een heel ander probleem.

De voordelen van losse bestanden wegen imho ruim op tegen alles in een file kwakken. Als het echt te groot wordt dan zip je gewoon even alle mail van een jaar / kwartaal, mailbox, whatever je handig vindt.

Klassieke harddisks zijn over 10 jaar toch verdwenen. SSD's worden steeds groter en goedkoper. Om dan te optimaliseren voor een verouderde technologie lijkt me een beetje onzinnig. Ook is die harddisk space die je meer kwijt bent niet relevant meer met de huidige opslagcapaciteit. En als het echt uit maakt, maak je de clustergrootte gewoon kleiner :)

als microsoft een formaat niet vrijgeeft, dan ligt daaraan dat microsoft oneerlijk kan concureren... vendorlock enz

als microsoft formaten vrijgeeft heeft de wereld daar niets aan...

als de wereld er niets aan heeft kan microsoft ook daar niet oneerlijk op concureren en kan er nooit sprake zijn van vendor lock.


Hij reageert op het feit dat Microsoft het nooit goed kan doen. In feite dus op het gevoel dat ik ook kreeg van bijna alle commentaren boven hem.

Ik vertrouw MS ook niet verder dan ik ze kan gooien, maar het feit dat alles wat ze doen meteen negatief benaderd wordt begint een beetje vervelend te worden. Als ze specificaties vrijgeven, doe er je voordeel mee of doe er niets mee. Hoe dan ook is het beter dan niets vrijgeven.

Er zijn bovenstaand terechte bezwaren tegen pst als een bestandsformaat geopperd. Maar voor de uitwisselbaarheid van mail tussen verschillende programma's is dit een goede ontwikkeling. Niemand heeft geclaimt dat nu alle programma's pst als bestandformaat moeten gaan gebruiken, ook MS niet.

Vrijgeven onder de Open Specification Promise.

See what's wrong there!??!

een Microsoft-programma dat ontwikkelaars vrijwaart van juridische vervolging als zij specificaties gebruiken die onder OSP zijn vrijgegeven.
Geef je even aan wat hier verkeerd aan is?

Promises promises... :p

We willen garanties, geen vage beloften.
Zie ook de Microsoft Community Promise voor .NET / Mono

Dit is geen vage belofte, maar ook niet echt een toekomstvaste belofte. Ik lees volgende:

New versions of previously covered specifications will be separately considered for addition to the list and are covered only if specifically listed.

Dit betekent volgens mij dat de belofte niets zegt over toekomstige versies.

Het lijkt me geen gezonde basis om een ICT-plan dat jaren mee moet op in te richten.

[Reactie gewijzigd door SimonKroller op dinsdag 27 oktober 2009 12:12]


Het lijkt me geen gezonde basis om een ICT-plan dat jaren mee moet op in te richten.
Dan kun je meteen alle open standaarden ook uit de ICT plannen schrappen want de licenties van de participerende leden op de gebruikte technology gelden alleen voor huidige versies en ook niet voor toekomstige versies.

Het is gewoon standaard om technologie licenties alleen af te geven voor current versies omdat je niet naar de toekomst kan kijken. Anders zou in de onzekere toekomst je grootste concurrent door jou ontwikklede technologie wel kunnen toevoegen aan een standaard om gratis gebruik te mogen maken van die technologie.

Dan kun je meteen alle open standaarden ook uit de ICT plannen schrappen want de licenties van de participerende leden op de gebruikte technology gelden........
Het gaat trouwens in mijn reactie niet om een standaard, maar om de tekst van een "promise".

Standaarden worden vaak door industrie-consortia, universiteiten, maatschappelijke organisaties ontwikkeld, dat geeft meer zekerheid dan de mogelijke kuren van een enkel bedrijf met toch al een slechte reputatie wat betreft openheid.

En vervolgens kun je je ook afvragen of je sommige specificaties uit die "promise" zou moeten gebruiken, omdat er voldoende alternatieven zijn die wel bij ISO of ECMA zijn gedeponeerd.

[Reactie gewijzigd door SimonKroller op dinsdag 27 oktober 2009 20:26]


Je vergeet 1 ding:
jij gooit alle reacties op 1 hoop, alsof iedereen dezelfde mening heeft. Het zijn echter totaal andere mensen die die andere reacties geven. De ene keer trekt een bericht de ene groep, de andere keer de ander.
Ikzelf ben een voorstander van open formaten (écht open, geen OOXML crap met gesloten delen, hè hAl :+), en ieder formaat wat MS open gooit is een stap in de goede richting. Die vendor lock-in attitude van ze kots ik al jaren op, en als dit een stap is richting minder lock-in krijgen ze van mij een duim omhoog.
Of het echt wat helpt laat ik in het midden, maar een vooruitgang is het zeker.


Voor dat soort dingen is er het Spel- en tikfoutjes - en dus *geen* andere foutjes - deel 34

Het is inmiddels al aangepast.

Of tweakers checkt zijn eigen spelling voordat ze posten? Schrijven is immers hun beroep en je zou best mogen verwachten dat nieuwsberichten niet om de haverklap worden aangepast na publicatie? Ach ik zal wel ouderwets zijn... degelijkheid en kwaliteit en zo...

Ja kan, maar het blijft mensenwerk, en mensen maken fouten:) Er is toch niet zoveel op tegen om T.net te helpen?

Ik ben zelf ook erg van de spelling en correctheid van teksten, maar ook bij mij sluipt er wel eens een foutje in.

Het zou wel fijn zijn als je zonder problemen je adresboek, email en andere zaken kunt inlezen in een ander programma dan outlook. Het huidige converteer-exporteer-importeer principe laat te wensen over.

Sws. het backuppen van Outlook is tragisch slecht geregeld.

En dat voor een business app.

De bedoeling is dat je outlook gebruikt als frontend van Exchange. Volgens mij is de backup van exchange prima. In een zakelijke omgeving wil je gewoon de mail centraal opslaan.

Daarnaast. De meeste applicaties hebben geen backup functie. De meeste mensen maken backups van hun belangrijke bestanden (inclusief pst files) of van hun hele machine. Ik zou gek worden als ik bij elk programma apart een backup moet gaan maken.....

Die bedoeling heeft Outlook zeker niet exclusief.

Iedereen moet weleens Outlook opnieuw installeren, vanwege herinstallatie oid. Het is fijn als je dan makkelijk je bestanden opnieuw inlezen kan.

Tenzij iemand kan uitleggen hoe je dat nu het beste kan doen.

Als je Outlook gewoon herinstalleert (zoals in bv Office verwijderen en terug installeren) blijven alle bestanden staan... geen werk hier dus.

Ik bedoel ook als je Windows opnieuw moet installeren..

als jij een nieuwe autoradio koopt dan komt hij ook direct op met je voorkeurszenders van de oude radio ?????

Ik moet hem toch wel even opnieuw programmeren hoor.

als je de hele boel onderuit schopt dan is het niet zo gek dat je even je instellingen weer terug moet zetten.

Eigenlijk vind ik het "backuppen" van outlook bestanden eerder handig om van outlook af te komen. Zo'n lekker programma is het nou ook weer niet, dus als je je pst files gewoon in Thunderbird zou kunnen importeren zou dat de wereld vooruit helpen :D

Outlook is ook gewoon een applicatie voor privé mail hoor, het wordt geleverd in alle office-pakketten, ook in het standaard pakket.

Dat Outlook ook door veel bedrijven gebruikt wordt lijkt mij meer een logische keuze gebaseerd op een aantal kenmerken van het programma; Email, contactpersonen en agenda gecombineerd in één programma. Andere email clients hebben die combinatie niet (missen bijvoorbeeld een agenda-functie) en moeten dus draaien naast een andere applicatie (zoals een agenda).

Het was fijn geweest als Microsoft een fatsoenlijk export- en backupfunctie ingebouwd had, dan hadden ze van mij dat bestandsformaat niet openbaar hoeven maken:)

In alle pakketten zit Outlook, behalve het pakket voor 'Thuisgebruik en Studenten': het privé-pakket dus. (Bron: http://office.microsoft.c...ducts/FX101635841043.aspx)

Met de Exchange-integratie ligt de focus echt op zakelijk gebruik. Voor privé-gebruik werkt Windows (Live) Mail waarschijnlijk handiger. Mensen gebruiken Outlook vaak thuis omdat ze het gewend zijn van het werk, echt niet omdat ze alle functies nodig hebben.

Nu .edb nog!

en .dbx

en .exe kan dat eigenlijk wel? :P

Een .exe bestand, is opgebouwd volgens het PE/COFF formaat. Dit formaat beschrijft eigenlijk hoe de diverse onderdelen/secties van een programma aan elkaar gerelateerd zijn. De daadwerkelijke instructies voor de CPU bestaan gewoon uit x86 en x64 bineaire instructies... Dit geld in ieder geval voor native applicaties.

.Net executables hebben ook een PE header + wat native code die zaken afvangt zoals het ontbreken van het .net framework (dat je bijvoorbeeld een melding krijgt om deze te downloaden), maar de rest van het bestand bestaat uit MSIL code.

Over het PE/COFF formaat is al heel veel informatie te vinden. Ook op MSDN: http://msdn.microsoft.com/en-us/magazine/cc301805.aspx en http://support.microsoft....spx?scid=kb;en-us;q121460

Het is misschien niet "open" als de defintie die hier tegenwoordig voor gehanteerd wordt, maar MS geeft er in ieder geval behoorlijk wat informatie over vrij en er is veel over te vinden vanuit derden. Je moet natuurlijk wel wat kaas gegeten hebben van de materie om het te begrijpen ... dit is wel even wat anders dan het uitlezen van een XML bestand zeg maar ;)

[Reactie gewijzigd door Laurens-R op dinsdag 27 oktober 2009 11:31]


En wat voor nut zou het hebben om het .edb formaat open te maken?

Net als het open maken van alle anderen formaten: de bestanden kunnen gebruiken in andere programma's, zodat je je MS software zou kunnen inruilen voor die van de concurrent als dat nodig is, ipv vast te zitten aan een complete MS omgeving omdat je je mail niet van exchange naar een andere omgeving kunt krijgen, en daarom tot in het einde der tijden een exchange server nodig hebt (omdat je anders alle oude mail kwijt bent), met bijbehorende client (outlook) en vanwege die client windows systemen, etc etc etc...
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 09:54 Video Assassin's Creed II
Vorige 08:49 'Nieuwe MacBook Pro's met Core i7 en Radeon-gpu op komst'
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011