In the Early Nineties I was Hired to Take the MSDN portion of Microsoft
into a document Library type of design.
A user would give a link to a Document, the app would then parse the
document for various type of mime and store them on a files system on
the network, was well as have key word search and Associative links from
one Document to another.
This was a Network Wide system that covered many offices of Microsoft
all over the world.
it was more a SGML before HTML AND XML became defacto.
It was Database centric in all the Network references to the pieces
were in the Database. The Department would setup its defaults for where
their document pieces were stored.
A department that was doing development in a particular area could call
up all the references already in the database and associate them with
their work.
Still to me this is the best marriage between the two worlds.
I see this along with using Open office to do the actual User interface
as the way to have a robust Document system.
I also believe the basic model for Ofbiz document container could be
enhanced to allow file type of documents in the Data resources.
Ean Schuessler sent the following on 10/13/2010 4:34 PM:
I agree that databases are very, very powerful but they also introduce
fundamental limitations. It depends on your priorities.
For instance, we've found that the processes companies pursue for
editing documentation can be every bit as fluid, complex and partitioned
as source code. I'd ask you, as a serious thought experiment, to
consider what the ramifications of managing OFBiz itself in a Jackrabbit
repository. Please don't just punt on me and say "oh, well source code
is different". That's an argument by dismissal and glosses over
real-world situations where you might have a pilot group editing a set
of process documentation based on the core corporate standards, folding
in changes from "HEAD" as well as developing their own changes in
conjunction. I've just personally found that the distributed revision
control function is fundamental to managing the kinds of real content
that ends up on websites. Maybe you haven't.
Scott Gray wrote:
This isn't about casting stones or attempting to belittle webslinger, which I
have no doubt is a fantastic piece of work and meets its stated goals
brilliantly. This is about debating why it should be included in OFBiz as a
tightly integrated CMS and how well webslinger's goals match up with OFBiz's
content requirements (whatever they are, I don't pretend to know). Webslinger
was included in the framework with little to no discussion and I'm trying to
take the opportunity to have that discussion now.
I'm not trying to add FUD to the possibility of webslinger taking a more active
role in OFBiz, I'm just trying to understand what is being proposed and what
the project stands to gain or lose by accepting that proposal.
Version control with git and the ability to edit content with vi is great but what are we
giving up in exchange for that? Surely there must be something lacking in a file system
approach if the extremely vast majority of CMS vendors have shunned it in favor of a
database (or database + file system) approach? I just cannot accept that all of these
vendors simply said "durp durp RDMBS! durp durp". What about non-hierarchical
node linking? Content meta-data? Transaction management? Referential integrity? Node
types?
