|
From: James R. <jam...@co...> - 2010-04-12 02:58:58
|
I was thinking today about file formats for our files. I've begun to read the book I bought to learn about SolidWorks, "Commands Guide Tutorial for SolidWorks 2010". I've only started (the book must be 800-1000 pages), but it's already apparent that the format for a SolidWorks file must be hairy indeed. We need a way to describe a hierarchy of descriptions: features -> parts -> assemblies -> libraries This is no mean feat, i.e., it will be hard work, and if the blender folks are resistant to us changing their code, they'll certainly be resistant to making _major_ changes and additions to the .blend file format. So, I was thinking that we should have some discussion about what our file format ideas are. I'll tell you my approach. This is not a file format problem, it is a database problem. There is more than one type of structure to define and sets of structures are related to other sets of structures. That's not simple, and to me, it screams "use a database, not a flat file". I worked in databases for about 15 years, so this kind of thing doesn't scare me at all. In fact, it seems like coming back to old friends. We could use something like SQLite for the time being, and we might decide it scales well enough to support a BlenderCAD single user. And if we would like to support network accessible data, it's a pretty straightforward application to develop using RPC or RPC-like tools (I would look at YAML as a transport format given some previous experience with XML - I'm not an XML format fan). And we could easily support larger systems, perhaps using PostgreSQL on most platforms and SQL Server on Windows, to allow multiuser library access. thoughts? -jim |