David Abrahams wrote: >If there's a postprocessing step, you can probably >support arbitrary formats. Maybe that's silly >though: there's probably no point in putting that >step in the library.
In a pedantic sense, I think given any non-lossy serialization S and complete meta-information M, it would be possible to define T(S,M) such that S' = T(S,M) yields some arbitrary format. So, given S, S', and M, is it possible to computationally infer T? Otherwise, you might as well postprocess S yourself. I suppose we could facilitate that by allowing a serializer object to accept a post-processing functor. This seems a little far fetched, but who knows. >Does "make a database" equate with "persistence" in your mind? No. Once you have a good persistance library though, it starts making sense to build a database of persisted objects. You use a database back end instead of a serial back end when you need fast store/load, fast searching, and all the other reasons you ever use a DB over a flat file. You could, however, persist to a serial archive and use that as some kind of save file; you could even make that archive some kind of XML so a human can read and modify it. Once you're using the persistance front end, though, you can (ideally) "upgrade" to a database backend transparently. Kind of like you can use an ODBC interface to a text file, and then upgrade to a "real" DB as your needs grow. Before, I've had save files generated with a serialization framework that reached its limits. I wished I could transistion to a DB, but the hit for re-architecting the app was too expensive. Our intent was to save and restore app state; we didn't care that it was serial--we had very different formats for serial network protocols. In that case, we got stuck with bad limitations--very large text files that had to be completely deserialized into memory (creating in-memory objects for everything), and then searching those in-memory objects for what we needed. >From a software eng perspective, I see serialization as a trap. It has lots of historical precedant (a good chunk of that from MFC), so people just kind of assume that it's the way to go for everything. Boost, however, is forward looking, and I see this as an opportunity to escape the trap. Serialization and persistance have different use cases and purposes. Most applications would have BOTH in my byte-stream utopia: persistance with a DB backend for local storage, and serialization to a variety of formats for data exchange with other applications or users. It's confusing because you can serialize and persist to an identical archive. Same observable results. Same ends, different means. It's a one way confusion, though: you'd never use a persistence framework when you need to serialize to some random format. Hope this helps. Cheers- Augustus __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
