As often said by Dr. McCoy in the original Star Trek series, he is a doctor, not a ____________ . However, just like Dr. McCoy, you may sometimes need to work on things that seem very alien to your experience. One of those things, might be JSON. LotusScript, which was derived from Visual Basic, was written long before JSON existed, and therefore, LotusScript had no built-in capabilities for handling JSON objects. As we mentioned in Part 4, JSON plays a critical role in iPhora. All data are stored as JSON, and JSON serves as the primary data and communication format between modules, functions and services. All core components operate using JSON-based configurations. Therefore, it was extremely important that we are able to fluidity create, read and process JSON. Creating a JSON string is relatively easy in any programming language. You can create it even using Commodore 64 Basic, and if built sequentially, one line at a time, it is possible to create JSON representations of ve
Comments
http://www.duffbert.com/duffbert/blog.nsf/d6plinks/TADF-7LY5CC
You saw Ed's recent post from this week I am sure as well.
If Integration is important, we integrate better to SP.
What the customer wants to do is important as well as Quickr can bring a company into Web 2.0 better than SP but again context is the issue.
I try to provide an ROI of 90 days or less for Quickr projects. Sharepoint can involve hardware and infrastructure costs depending on how they want to roll it out.
Replication for remote locations might be a good selling point as well as Quickr with DAOS can reduce network traffic and disk space usage.
Thanks for the information. I must have missed these two posting. I need to take a look.
Richard
Unless I missed something, neither posting really cover a comparison between SharePoint and Quickr.