Gat1024: Try grabbing the dead OpenDoc spec at look at their bento container. It's design goal is exactly like *.doc.
I worked on Bento. I was not the designer. Jed Harris was the designer (Ira Reuben the coder). Jed said Bento was an experimental first cut prototype that was pushed into production, and I agree with this view.
The design goal was only rather similar to *.doc. Unfortunately, since Bento was a version one prototype, it never had a redesign for ease in reading and writing until I designed one.
Gat1024: And that was designed from the get-go to be cross platform.
It was technically cross platform, but Bento was very unfriendly as a clearly understandable format. It's big mistake was to use phsyical stream embedding instead of logical embedding, so the recursive flow of control was a nightmare to analyze. The format had physically discontiguous streams embedded inside other physically discontiguous streams, which would give almost anyone the shudders.
Gat1024: Think of it as component hell. And it is unavoidable no matter who does it. This goes for KOffice as well. Complexity is a run away train. I should say entropy. Since we're tending towards chaos here.
You are correct that every open format can embed opaque content that cannot be understood, so all component systems suffer from the risk of component hell.
I would not accept any amount of money to reverse engineer the Office doc format as a regular job, because it would tend to be too hard and frustrating to deal with the complexity under ongoing changes.
Furthermore, I would not trust any junior engineer who did accept such a job, so I would avoid the product based on such work, under the theory it would be fragile and buggy. Am I a pessimist, or what?
I plan to use this methodology when I have more of Mithril and IronDoc done. Right now I only have vague plans for Bolide described at (for example) the following pages:
I'm familiar with this kind of problem. Here's the basic conflict that I see, and I have trouble seeing a solution you can follow, unless your company will cooperate with you.
You're still developing on your own time.
What you develop on company time probably belongs to the company.
Your intellectual property agreement probably says that whatever you do on your own time related to your company's business ALSO belongs to them.
By asking you to work on your own free code, they are coopting your work so you can't make it free in the future, even if you were already headed in that direction.
You intellectual property rights are being contaminated with those of your employer.
If you have a disagreement, who do you think will win, given your IP agreement?
You should tell your company about your situation, but I'm not optimistic about the outcome, because as near as I can tell most companies seek this kind of conflict on purpose. That is, they like to hire folks and coopt the intellectual property of new employees.
You can tell the intent from how they react to your description of the problem. Passive aggression is a bad sign, and this is characterized by remarks that sound like "I don't see why there's a problem."
All the following merely excerpts my 19April2000 rant on opacity in proprietary formats, and the effects of potential XML usage by Microsoft.
[quote] The context for this page is best stated in my initial brief correspondence with Dan Gillmor. I previously described this page as an essay about ensnaring open systems with trace amounts of proprietary content, or about making systems so complex that only large teams can easily accomplish productive development. [snip]
All open formats which support general embedding can embed cryptic closed content as easily as transparent open content. This includes text formats like XML as well as binary formats like IronDoc.
Using an open format does not guarantee openness. Only a commitment to avoid closed content ensures openness. So using XML does not prevent embedding of cryptic proprietary content inside open standards.
Similarly, all open source projects can be used to write mysteriously complex systems as easily as lucidly simple systems. This includes proprietary systems that become open source as well as historically open systems.
Neither using open source nor converting to open source guarantees an operating system will lower barriers to entry for competitive development. Only a commitment to avoid complex and ever-changing systems will work. So opening source code does not prevent ongoing propietary control.
Slashdot Mirror
They aren't the smartest. I answered the question on difficulty back in April:. htm
http://www.treedragon.com/ged/mc/te/officeformats
David McCusker, former OpenDoc guy
I worked on Bento. I was not the designer. Jed Harris was the designer (Ira Reuben the coder). Jed said Bento was an experimental first cut prototype that was pushed into production, and I agree with this view.
The design goal was only rather similar to *.doc. Unfortunately, since Bento was a version one prototype, it never had a redesign for ease in reading and writing until I designed one.
Gat1024: And that was designed from the get-go to be cross platform.
It was technically cross platform, but Bento was very unfriendly as a clearly understandable format. It's big mistake was to use phsyical stream embedding instead of logical embedding, so the recursive flow of control was a nightmare to analyze. The format had physically discontiguous streams embedded inside other physically discontiguous streams, which would give almost anyone the shudders.
Gat1024: Think of it as component hell. And it is unavoidable no matter who does it. This goes for KOffice as well. Complexity is a run away train. I should say entropy. Since we're tending towards chaos here.
You are correct that every open format can embed opaque content that cannot be understood, so all component systems suffer from the risk of component hell.
I would not accept any amount of money to reverse engineer the Office doc format as a regular job, because it would tend to be too hard and frustrating to deal with the complexity under ongoing changes.
Furthermore, I would not trust any junior engineer who did accept such a job, so I would avoid the product based on such work, under the theory it would be fragile and buggy. Am I a pessimist, or what?
David McCusker, former Bento guy
- http://www.treedragon.com/ged/ni/ni.htm
- http://www.treedragon.com/ged/mc/ in/jp03Jan00.htm
- http://www.treedragon.com/ged/mc/ in/dh15Feb00.htm
and assorted other pages near those.David McCusker
- You're still developing on your own time.
- What you develop on company time probably belongs to the company.
- Your intellectual property agreement probably says that whatever you do on your own time related to your company's business ALSO belongs to them.
- By asking you to work on your own free code, they are coopting your work so you can't make it free in the future, even if you were already headed in that direction.
- You intellectual property rights are being contaminated with those of your employer.
- If you have a disagreement, who do you think will win, given your IP agreement?
You should tell your company about your situation, but I'm not optimistic about the outcome, because as near as I can tell most companies seek this kind of conflict on purpose. That is, they like to hire folks and coopt the intellectual property of new employees.You can tell the intent from how they react to your description of the problem. Passive aggression is a bad sign, and this is characterized by remarks that sound like "I don't see why there's a problem."
David McCusker
[quote] The context for this page is best stated in my initial brief correspondence with Dan Gillmor. I previously described this page as an essay about ensnaring open systems with trace amounts of proprietary content, or about making systems so complex that only large teams can easily accomplish productive development. [snip]
- All open formats which support general embedding can embed cryptic closed content as easily as transparent open content. This includes text formats like XML as well as binary formats like IronDoc.
- Using an open format does not guarantee openness. Only a commitment to avoid closed content ensures openness. So using XML does not prevent embedding of cryptic proprietary content inside open standards.
- Similarly, all open source projects can be used to write mysteriously complex systems as easily as lucidly simple systems. This includes proprietary systems that become open source as well as historically open systems.
- Neither using open source nor converting to open source guarantees an operating system will lower barriers to entry for competitive development. Only a commitment to avoid complex and ever-changing systems will work. So opening source code does not prevent ongoing propietary control.
[/quote]