My company is currently using Open Text Livelink as a Document repository, we are debating whether to custom write our own document repository in java or us an open source document repository like Alfresco. What are the pros and cons to both methods?
When you build your own repository you can control what comes back out.
con: you have to build an interface for all types of documents you want to read in.
con: you are always updating to support changes to existing formats and accept new ones.
When you use a canned toolset you only have to incorporate it into your project
con: you have to wait for updates and make changes to accommodate new updates
con: only supported documents types can be used.
I ran a project using a 3rd party software to import the documents into a TIFF format, the biggest problem we had was keeping up with updates and delaying updates to our toolsets until new 3rd party tools were available that would support the new toolsets. We also suffered the ultimate fail in support from the 3rd party vendor--they went out of business. When they did we chose to rewrite using out own design--that product is still in use now some 15+ years later.
Out on HF and heard nobody, but didn't call CQ? Nobody heard you either. 73 de N7GH
Tremayne Smith wrote:My company is currently using Open Text Livelink as a Document repository, we are debating whether to custom write our own document repository in java or us an open source document repository like Alfresco. What are the pros and cons to both methods?
I'd say it depends entirely on what you need to do with those documents. View them? Print them? Search them? Present them as a "website"?
I worked on just such a project (the latter two) about 15 years ago - which oddly enough, introduced me to Java - but unfortunately the world wasn't quite ready then, and I spent many months struggling with MS Office Automation ... without doubt the worst piece of software I've ever had to deal with.
If you just need a "manager" of native documents, then I suspect you'll be fine either way; but if you need anything more (eg, conversion to HTML, global searches, versioning, etc) then you might want to go with a third party product, because they will (hopefully) have already been through the "learning pains" for you ... and they're considerable.
If you do decide to "roll your own", let me warn you: The worst documents you'll have to deal with will be MS Office ones; and they're likely to be a large proportion of them.
Why? Because Microsoft doesn't want you "doing stuff" with their documents - or if you do, they want you to buy their software.
(DON'T, btw. It'll be proprietary - ie, useless for anything else - and phenomenally expensive)
The trouble is that even in these days of Apache POI and the OpenOffice (or Lucene) Java API, you won't be dealing with native documents, and may have to wait for updates to handle the "latest and greatest". The latter is probably a "90% solution" - and I wish it had been around back in 2001/2 - but it's quite a learning curve; and you'll still have other proprietary formats like Visio (or whatever it's called now) that you may have to deal with.
About the only other advice I can give you if you decide to go the third-party route: Favour products with a good Java API. That way, if there are any "goodies" missing, you'll be able to write your own modules to cover it.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
And when my army is complete, I will rule the world! But, for now, I'm going to be happy with this tiny ad: