Oct 5, 2009
Many of the comparative articles I found were written from a marketing viewpoint, but not actual developers who had hands-on experience with both frameworks. Here are a few of the entries that found during my research:
Drupal vs. SharePoint
To Compare DRUPAL and SHAREPOINT 2007
Microsoft kill Drupal? (for laughs)
Drupal vs. SharePoint
To Compare DRUPAL and SHAREPOINT 2007
Microsoft kill Drupal? (for laughs)
In my experience, SharePoint does not live up to the hype for a variety of reasons. SharePoint 2007 is being positioned as not only an intranet platform, but also a web framework that can power big sites and be on the same playing field as other larger CMS platforms, like Drupal.
To preface, I am not here to argue with SharePoint's intranet capabilities. The platform has Microsoft product integration and file management features which Drupal does not have yet (other than some basic file manager modules to the best of my knowledge). As I understand, Drupal was never intended to do heavy lifting management of documents, but there is no reason why it could not grow as an intranet platform. However, that is a whole other discussion.
From my vantage point, I have identified six major differences between SharePoint and Drupal. They include:
- Setting up a local development environment is difficult and expensive.
- Setting up an efficient development/deployment process is cumbersome.
- Theming SharePoint is extremely difficult.
- Many SharePoint modules (aka webparts) are quirky and don't work as expected.
- Lists and libraries are quirky and also often do not work as expected.
- SharePoint is slow and does not give you real access to the database that powers it.
1. Setting up a local development environment is difficult and expensive.
First, SharePoint is extremely difficult to set up on a local box. That is because you need Windows Server to run a SharePoint website and you have to have a SharePoint site to create web parts for that site. Thus, either your local box needs Windows Server 2003 or higher or you need a virtual machine that runs both. Furthermore, developing in Visual Studio in a virtual machine is arduous. Aside from the CALs and licenses you need for each developer you are married to getting four gig or higher machines. Now, maybe we are already to the point where that is not as much of an issue, but at the time, several of my colleagues had two gig macbooks that could not be upgraded. Basically, we had to try to run a VM in one gig, which is basically impossible. What we ended up doing was using remote desktop to connect to our own personal instances of Windows Server 2003 where we could develop against a site that had four gigs of RAM. For the most part, we could run some Visual Studio and Designer Studio locally until we deployed changes that we might have to test on the VM itself. To summarize, getting set up is expensive and requires heavy hardware.
Drupal response:
Drupal is extremely cost efficient to get up and running. You can run Drupal on virtually any platform and you do not need a heavy-duty machine to run most sites.
Drupal and editor tools like Eclipse are both free to use. In addition, the entire catalogue of Drupal modules is open source, and many are very well supported by the community.
2. Setting up an efficient development/deployment process is a pain.
In my opinion, deploying a SharePoint site requires that most organizations have a Microsoft Server sys-admin. I really do not think most organizations that are deploying SharePoint sites (as external websites) can manage without a Microsoft sys-admin on the team. The fact that developers are handcuffed to a sys-admin even while developing is one reason deployment is a pain. Second, there are a multitude of steps for pushing web parts to different environments. And webparts are the easy part. Developers have to deal with compiling dlls and adding things to the GAC and configurations and restarting IIS, so it's not exactly plug-and-play. However, webparts can be streamlined. Pushing the entire site to another environment is also not really difficult. Basically, what is impossible is trying to push a subset of data. You might think lists and libraries could be exported easily but in fact when we tried we lost the associated metadata which basically makes a list worthless. To be frank, there is not a good way of exporting/importing data to/from environments. Our team had to create one development environment that was "staging” that was treated just like production because we would push to production eventually from staging. Again, all of this can be streamlined to some extent but getting to that point is a very frustrating process. We had three developers, a sys-admin, a SharePoint expert and it was still an arduous process.
Drupal response:
Setting up a Drupal development or production environment is also easy. With svn the development team can check out files onto a development environment and push its db changes. Drupal runs on PHP which runs on virtually any environment, and you don't have to be a server expert. Many people launch Drupal sites on shared environments without any deep technical knowledge.
3. Theming SharePoint is extremely difficult.
The theming process requires SharePoint Designer 2007. And that means more money will have to be spent for each copy of program, and that is in addition to the tens of thousands of dollars it already costs for all the other licensing an organization needs to get a SharePoint site up and running. SharePoint Designer is not terrible as an editor but the check-in, check-out system of version control can be maddening. It is very frustrating in my experience to work with a team of designers/developers/admins touching aspx files and constantly seeing that someone forgot to check-in a file. What this leads to is either you have to override it (which could make the other person lose their changes) or get the last person who edited the file to check it in. Doing so will not reveal the changes to a public user so you must also then publish the file. Publishing files in SharePoint Designer gives you an error (has this been fixed?). To further complicate matters, you then have to log onto SharePoint and drill down to the file to publish it for anonymous users to see the changes.
If you can get past file management you will find that doing any amount of theming in SharePoint requires some knowledge of XSL. Other Content Management Systems (CMS) use XSL and there is probably some valid reason why though I don't know what it is, because I find it very limiting. I prefer Drupal templates that are more straightforward and can use PHP to manipulate the theme layer. With XSL, you have to find XSL functions to try to accomplish what you want and again that can be very limiting. And I never understood why aspx files do not have conditionals unless C# is enabled (which is a security risk). Why is that important? Because often times you have markup that you do not want output unless you get a value you are expecting. For example, if you are styling a div a certain way, you might want that div only be rendered if it has a value, I ended up having to use jQuery to get around these limitations.
Finally, SharePoint's markup is completely terrible, non-standards compliant, and non-sensical. There are some CSS files and ids/classes in SharePoint markup, but they are completely misused. To list a few items: really long IDs, embedded tables, inline css and non-standard compliant html. This is very difficult to style unless you have an out-of-the box SharePoint site or buy a pre-made cookie-cutter template for the site. And that underscores the problem of SharePoint 2007 growing out of an intranet platform into a supposed web-publishing platform. When SharePoint was merely an intranet platform, theming didn't matter much because it was only seen by employees. Now developers are being tasked with creating widgets and creating layouts but the theming layer is just is not up to par.
Drupal response:
Drupal's theming layer is very powerful and flexible. It is constructed in a way that scales well with a themer's knowledge, meaning the more you know, the more powerful it is. But a lot can be done with CSS and a few template changes. It does not require in-depth knowledge of phptemplate functions and form overriding, but it helps to learn such things when you get into advanced theming. Also, everything is in PHP so if you know PHP it is easy to get started.
4. So many SharePoint modules aka webparts are quirky and don't work as expected.
The Content Query Web Part (CQWP) is supposed to be this heralded feature that allows for pulling content easily, but I contend it is not. First, the output is hard to theme. That goes back to my point about having to work with XSL. And many of the XSL templates are in tables. A big problem with the CQWP is that it does not ship with anonymous access. Developers find out quickly that getting anonymous access to certain features, like the blog for example, is not so easy. You can read more about a workaround to this issue here. It goes back to my central point, the question one must ask – “Why is this so hard?” Why do developers have to waste time finding a work around for something so simple? And this raises the question also, why has this not been fixed? I contend that if a problem like this existed in a Drupal core module it would be fixed immediately. And that is the advantage of having a community supported platform instead of a system that only gets upgraded every couple years and charges money for those upgrades.
Drupal response:
Drupal core modules make sense. The top contributed modules make sense. That is because there is an active community behind Drupal modules and not a large inefficient corporation. The Views module beats the CQWP by a huge margin, in my opinion. The power of Views 2.0 especially is amazing and CQWP simply does not compare. Views allow for ultimate flexibility and have a powerful theming layer. If you want a more powerful CQWP you have to pay for it from a vendor that creates an advanced webpart or search places like CodePlex, which does not have near the number of developers in its community.
5. Lists and libraries are quirky and also often do not work as expected.
We already addressed the quirkiness of exporting/importing list and library content, but there are also strange permission issues that come up. Some list data in particular is not available anonymously, such as most notably the calendar item list. The problem is not viewing an event in a list, rather the problem occurs when the user clicks on an event to view the details. That will by default prompt a popup authentication box which for a public website is typically not the intention. So far all the granular and inherited permissions SharePoint has items like this fall through the cracks. Our team had to find yet another work-around to solve the issue, which involves a small hack to an include file somewhere. It is possible at the time of this writing, some of these issues have been fixed, though let the record show that Sharepoint was released in 2007 and our team had these problems into early 2009. Also, there are inheritance problems when you get into lists in sub-sites that is beyond the scope of this discussion. The point is that lists and libraries which of comparable to “node” content in Drupal, are entirely too obtuse and don’t work in a straight-forward matter when it comes to web-publishing.
Drupal response:
Drupal's node system is amazingly more powerful and easier to use than lists. The Content Construction Kit (CCK) allows for tremendous flexibility and power with content, often times not requiring deep technical knowledge. For libraries, developers can create files with meta data using CCK that emulate some of the features of libraries though it is not an exact comparison. Namely, there is no messy inheritance to deal with when managing node content types. Instead of inheritance, CCK uses composition which in my opinion is much more flexible and easier to understand.
6. SharePoint is slow and doesn't give developers real access to the database that powers it.
SharePoint does not give developers access to the SQL database that powers it, well technically they cannot prevent them from touching it, but that can lead to data corruption, so it is really not a good idea. Furthermore, even if one could analyze the database the structure is difficult to understand. One issue I have is that SharePoint stores everything in blobs. That to me does not seem like a really scalable solution. Also, sharing data requires the “Business Data Catalogue” and more confusing tasks in order to share data with another system. Our team did not get into that too deep on the project we worked on so I can’t get into great detail regarding the BDC.
I do find it problematic that developers cannot access the database. I think ASP.NET developers and open-source developers are quite used to dealing with the database directly so it can be frustrating to not have access when troubleshooting issues. Developers do have access to an API they can use from within SharePoint as long as they are running SharePoint on the same platform they are using to write code. The problem is that often time developers need access to the data in another environment like staging, for instance. Copying all that data is a hassle. Another option is to fake it locally, but then problems can occur when that webpart is pushed to production and it does not work as expected. And so SharePoint is not exactly the snappiest site in my experience. I do not have benchmarking statistics. I am just speaking from personal experience. The instance on our local boxes consumed a lot of resources and development was on a high end server and still not very snappy. Our team ended up using a system where we had a content server that pushed data to a static server. That ended up being a pretty efficient solution, but cost can be a factor there as well when you are talking about a multi-node system. The problem with that kind of a setup is that it means updates are delayed – for many organizations that is simply not an acceptable solution. Many publishing sites require content be updated immediately.
Drupal response:
Drupal gives you real access to a real database and it's actually optimized out of the box and makes sense. Developers can inspect the database tables and make sense of what is going on. This is not required for a non-technical user, but is very handy for a developer. Drupal gives you many out of the box performance features like caching, menu caching, form caching, page caching, CSS/JS caching (a fantastic feature) and block caching. Those default options alone give sites big performance gains. There are still ways for a programmer to create an inefficient site but in my experience most popular contributed modules are well-tested and perform well.
To recap, I hope that this article was helpful for developers or managers looking into SharePoint vs. Drupal. My objective was to give an in-depth look into the two platforms from a developer on the front lines, who has actually developed for both platforms. There are many posts out there on the web from people who have not actually programmed against one or either platform and therefore cannot give an accurate comparison. SharePoint does not fail in the abstract, no platform does. My point is that the abstract features of SharePoint are not the issue, it is the real-world implementations of the platform that leave it severely lacking when it comes to web-publishing.
It is my opinion that this can lead to a development staff being saddled with a platform that can be very frustrating when it is found out it does not live up to the hype. My aim has not been against SharePoint’s intranet capabilities, rather Microsoft’s claims that it can be a major player as a web publishing platform. Also I would warn that businesses investing in proprietary tools of this size could fall into a perpetual upgrade trap – once you put money into a platform this big it can be difficult to leave. Therefore, for all the reasons I have detailed above, I implore managers to save the headaches and dollars and invest in a powerful community supported platform like Drupal. You will not regret it.
Comparing SharePoint and Drupal isn't very fair as they both have different uses that they're best for. I'll admit however, that the area between the two different products is definitely starting to become a blur as each product grows.
What it basically boils down to, is if the company can afford SharePoint (including the expensive stack technologies) they'll probably go with it. SharePoint's strengths lay within its ability to seemlessly integrate with windows OS/Sharepoint Designer, InfoPath, and office products. The problem is, you can't do SharePoint one foot in and one foot out. You have to spring for an all-Microsoft way of doing things - which can be awesome, but extremely expensive.
Drupal makes kick*****websites with very minimal effort and even less cost (there are always hidden costs with open source.)
Anyways: if anyone wants to here a sharepoint biased opinion check this out: http://www.elliottbeaty.com/wordpress/2010/06/microsoft-office-sharepoin...
Don't forget that Sharepoint uses GUIDs everywhere, so you have 32 character strings, and they WILL be different on your development and production environments.
A: I am currently a Linux & Mac System admin with a strong Windoz Admin background.
B: I have been a web developer for 10 years
I am having a blast in SharePoint and Designer, I love the document handling, I love the Workflow tools, the integrated Variables, the way I can create my own flow and tools with a little help from the designer.
I am also loving the non-programming of things, the point and click, the simplicity.
On the downside themes are a pain compared to opening a text editor and moving HTML, Divs and CSS, but thats because of the Master Page effect!
Anyway
I am an old school Geeklog user, and I have a couple Joomlas, Its all good.
I found this comparison interesting. I’m glad you posted it. However, I have some factual corrections/comments that should be addressed:
1) Theming does not require SPD; it's just CSS and you can use any text editor.
2) No licensing for SPD; it’s free from MSFT and it's been that way for a while now.
3) Everything in SharePoint can be made anonymously accessible if configured correctly; there's a feature that turns off some of the administrative interfaces and you simply have to deactivate that feature to see the details behind the calendar entry you mentioned.
4) It’s very possible to run a SharePoint dev environment on 1 Gb and it works fine (though more memory is better)
5) The description of the Business Data Catalog's purpose is not accurate and the scenario I think you're describing doesn't match the BDCs design goals. That said, you're certainly right about the database behind SharePoint. I think, though, you point to a philosophical difference than a particular advantage; Microsoft never intended developers to hit the database directly and built a pretty extensive API to handle the interaction between SharePoint and custom code.
6) The CQWP is stylable via XSL and you can do what ever you’d like with that styling, including removing tables (though I’d admit it should be easier and it’s curious why Microsoft did not make this so). I saw the comment about XSL being a "developer" language and I would have to disagree. XSL is no more a "developer" language than HTML (since they both stem from the same SGML base).
7) Setting up a development environment isn’t difficult and I think you wrongly assume the installation of your PCs OS (advantage Drupal). You also assume that you'd have to install a server OS to begin SharePoint development (disadvantage SharePoint). To compare fairly, you should count the total number of hours (or tasks) for each environment without assumptions (including installing an OS, development tools, etc).
8) Licensing with Microsoft is unecessarily complicated and often expensive for large deployments (I'll grant you that). However, it’s not really all that expensive for a developer. One MSDN subscription is all that’s required for all license necessary for a development and test environment (though it's per developer on the development front, you can have an unlimited number of testing users). The subscription is yearly and gives you access to everything you need (e.g. Visual Studio, SharePoint, Windows Server, etc).
Thanks for your comments although may I fact check your fact checking? I have a few notes:
Thanks for indulging me, I appreciate your feedback. -J
A "crowd-sourced" comparison table:
http://www.cmsmatch.com/compare/content-management-systems/11+986
(Although the scores are not weighted.)
Thank you sooooo much telling the truth about Sharepoint. Alfresco made a Whitepaper about hidden cost and complexity about Sharepoint too few moths ago.
Unfortunatly, big company choose Sharepoint because it is "Microsoft" and saw hidden painful cost too late... They did not accept to rollback after spending so much money in licenses and hardware.
Few little questions:
- How much cost a Developer environement ? (Hardware + 2x WS2003 + VisualStudio + Visual Designer, ...). And production environement ?
- How long does it takes to develope a given Webpart ? Like displaying some contents, sorted, with rights, ... in a fancy box ?
- How long does the full project takes and cost ?
Many thanks for your FeedBacks, we are often in competition with Sharepoint and it is a pain to see political choice winning over technical choice.
Absolute classic... companies that don't back out after spending extraordinary amounts of money. After all, the often quoted price of $40000 is nothing other than wishful thinking.... development environment, hardware, windows server, sql server, public connector license, cals, sharepoint itself and last but not least the cost for development.
Also, what many forget: the company's client environment may also have to be updated. You need something Microsoft calls a "Level 1 browser" (IE7 or 8) and for Sharepoint to work perfectly you need Office 2007 as well. Without realizing it the company is completely locked-in to Microsoft products in no time at all.
There is one grain of hope though: I've actually seen a company back out when their Sharepoint-project reached a cost of an estimated €9m (consultants directly form MS, hardware, licenses).
Incredibly, after all that money they spent all they had was a tiny page partially consiting of iframes pointing to a existing Java-based solution and a painfully slow document area.
A couple answers based on my experience:
- How much cost a Developer environement ? (Hardware + 2x WS2003 + VisualStudio + Visual Designer, ...). And production environement ?
Well a Sharepoint license for web publishing is $40,000 give or take last time I checked: http://office.microsoft.com/en-us/sharepointserver/FX102176831033.aspx -- so there's that and I believe that's for every site, maybe you get bulk discounts for multiple licenses. Hardware is cheaper these days so you can get pretty good hardware on the low-end for $500 to $2000 on the high end but I think the important point there is that you're probably forced to invest in new hardware if you haven't upgraded in a couple years. Visual Studio retails from a couple hundred to a few thousand but then there's MSDN and bulk discounts and whatnot that can complicate that number. Visual Designer I don't think is very much, maybe $80 and that's a drop in the bucket when you compare it to all the other costs. But you have to have licenses for every developer using those programs and on the Sharepoint license even though you don't need cals for public users it was my understanding that each developer working on the Sharepoint site needed a CAL -- on that last point I believe we had some confusion as to whether or not we needed a CAL for each employee working on the site so don't quote me on that.
- How long does it takes to develope a given Webpart ? Like displaying some contents, sorted, with rights, ... in a fancy box ?
The webpart might be the easiest piece once you get going, the problem we had was the documentation on the web and the books we bought was not very good nor up to date. As of 2008 when VS release some new extensions for VS 2008 we were able to create webparts much more easily because Visual Studio did a lot of the work for you that you used to have to do manually. So our frustration was that there wasn't any documentation of this. What we did was create user controls that were independent of Sharepoint and then make a Sharepoint "connection" webpart that basically initialized the user control which turned out to be a very clean way of implementing webparts. Again this was not something that we found in the big books we bought, but something we figured out ourselves. A webpart once you learn how to create/deploy one, should only take as long as creating any aspx user control.
- How long does the full project takes and cost ?
Well I'm sure that varies, for my team that worked on it, it took a lot of people to get it going so I'd say a big drawback to Sharepoint is that you're going to need more people, in particular a Microsoft Server expert if you want to get a site launched. That in addition to softrware/hardware costs makes it a pretty expensive venture, especially for small businesses.
I've run a site in Microsoft CMS (the precursor to SharePoint's web publishing system) for five years now and had to evaluate moving the site to SharePoint or another CMS due to the retirement of MCMS as a supported platform. We ended up picking Drupal, for some of the reasons you outlined above, particularly the inflexibility of certain themeing systems in SharePoint, the limitations of the API (try to change the title of a SharePoint generated RSS feed item to something other than the list item title), the difficulty of deploying changes to production, and the costs associated in setting up and running a robust MOSS site. The deciding factor was that we really didn't need many of the features SharePoint offered: document management, the BDC, the search engine, blogs, wikis because we run other platforms for those functions and if we were only using SharePoint to run a CMS it would be more efficient to use a platform that can be just a CMS (though, yes, Drupal *can* be much more).
I do think you overstated the difficulties of working with some aspects of SharePoint. Your argument against the themeing system is really that you're more familiar with PHP than XSL and C#, which is fine, but not always the case. Your complaint against SharePoint's lists is that they are difficult to export and move between installations, which is also true of Drupal nodes. I also think you were a bit selective in picking the features to compare the two products. SharePoint offers much better support for defining roles and permissions, and a better interface for doing so, than Drupal. This is particularly true when it comes to delegation of permissions. SharePoint also makes the process of defining a site hierarchy simpler than it is in Drupal. True, these aren't strictly development issues, but Drupal's solutions to these problems will require attention by the development staff to put in place.
XSL vs PHP might be preference, I will give you that. In my opinion XSL has a steeper learning curve than PHP when it comes to theming especially because most of it is HTML which people already know. XSL syntax is difficult to learn and I don't like troubleshooting XML in general because errors often fail silently.
You are right about pushing nodes across environments in one sense. To move from 1 different site to another would be very tricky and require custom code. However my point about having access to the database is important here. As a developer I know which tables hold the node data, eg node_revision, node, content_type_* (CCK), etc and so I could export/import that data via phpmyadmin pretty easily. There might even be a module that does that with a UI.
I would repectfully disagree on permissions, other than it is nice to have active directory integration out of the box. We had a lot of trouble with permissions and permissions inheritance, I feel like Drupal's grid permissions are straightforward whereas with Sharepoint it can be confusing to track what's going on in subsites. Also it's permissions doesn't cover everything like anonymous access to viewing list items (such as calendar events, blog posts to name a couple). Those quirks I'm sure have either been fixed already or will be fixed, but it's annoying to me they weren't fixed in late 2008 when I was working on a Sharepoint site.
Thank you for your comments, you raised some good points to consider. -J
XSL vs PHP : Webdesigners knows Photoshop. Some of them knows HTML and CSS. No one know XSL. It is a Developper language not a designer language. PHP and JSP are the bridge between Webdesigner and Webdevelopers that's why so many people like it and use it.
Regarding not accepting the attachment method see http://drupal.org/node/438940.
Thanks for this great article Jay.
Same here. I'm an administrator web working with both Microsoft and Drupal. Overall I better like Drupal. But SharePoint currently lead in document management and search.
I would add two points to your list. First Drupal is more secure because updated more often than Sharepoint. Second Drupal has a better support/service because Drupal community of contributors is much bigger, keen on sharing knowledge and accessible for free.
Drupal is getting better at handling documents. Here are a few options.
-Open Atrium. A Drupal powered Intranet with document handling. "A simple online handbook that lets you collaborate on documents, store and compare revisions, attach files, and once you're done print out the final copy." Read more at http://openatrium.com/features
-'Apache Solr Attachments' module http://drupal.org/project/apachesolr_attachments
-'Search Files' module http://drupal.org/project/search_files
-'Search Uploaded Files' module http://drupal.org/project/search_uploads
-'Swish-E Indexer' module http://drupal.org/project/swish
-More modules at http://drupal.org/project/modules?text=search%20file
I'm guessing open atrium works like basecamp where you still attach files and Sharepoint allows you to drag files around and Sharepoint becomes aware of those files. I don't know exactly how Drupal could replicate that, for 1 reason Drupal is usually run on linux boxes. It might be possible on a Windows box to create a similar workflow using Active Directory, but then non-Windows users wouldn't have those features.
I would think one option would be to have an executable that runs natively on an OS (java-powered perhaps) that gives you a windows-like navigation through files. You could have it authenticate the user's credentials and then the user could drag and drop files and behind the scenes those files would be uploaded via FTP to the appropriate place.
You could create a module that monitors the settings/permissions that accompany the file permissions. I am not aware if anything out there does this but that seems like a decent workaround to accomplish drag-and-drop file management.
It still wouldn't give you inline document management, that is where you can click edit on a document, it pulls up externally or in the browser, you make changes and click save and it saves the document back to the system. Sharepoint does that and that would be difficult to accomplish without some heavy duty activeX knowledge.
You're exactly right. Open Atrium is terrific, but the files are attached to nodes, and while the resulting knowledgebase type functionality is great, it doesn't replace Sharepoint's drag and drop file management. Not to complicate matters, but the best alternative I've found is Liferay (www.liferay.com). It's java based--so it needs an application server, and modifying code can be a pain--but it has WebDAV support out of the box, and a decent workflow process. We use Drupal (corporate website), Sharepoint (intranet), and Liferay (partner portal) right now, and I think Liferay has a better chance of knocking SP off its perch at our company than Drupal does.
I will have to check that out.
I have been stuck with one foot in sharepoint and one foot in drupal for over two years now. I couldn't have expressed the relative strenghts and weakenesses better myself. You totally nailed it. I've gotten to the point where I only use sharepoint for document management ( I setup some document libraries in sharepoint and use the cck link module to replace upload/filefield to simply present document 'attachments' (which are just links to sharepoint docs).
I tried knowledgetree and alfresco but integration was awkward and heavy. This seems to work well so far.
I would love to dump sharepoint altogether, but users simply will not accept a detaching, editing, and attaching workflow for documentation management. They simply want to click and go. It wouldn't matter if a drupal site could serve them coffee and cake-- they simply won't stand for the attachment method of document management.
Post new comment