Adobe giveth and Adobe taketh away - No more SOAP collaboration

Are you very sure that it was 'discontinue" and not 'deprecate' There are still many features of Acrobat JavaScirpt that have been replaced by other methods but are still available. For a real example look at how Adobe handled the ADBC object with the introduction of Acrobat 8 and 9. It is still available if one wants to perform the necessary setup. And most users do not work on their systems at the registry level. Or the the evolution of Reader and the LiveCycle Designer XML forms. Now may users need to update from Reader 4 to Reader 8 or 9 because of the change in the program used to design forms. Forms designers have issues with the increased security restrictions in Acrobat JavaScirpt, but there are some work arounds.

Discontinuing support means Adobe will not add new features to the SOAP interface evolves. They may update the interface as serious issues evolve.

I would expect SOAP will be available at a limited level for versions 10 and 11 and then it will be fully replaced by newer collaboration technology.

How many computer languages have come and gone?

What has happened to the applications written in those languages?

When I learned SAS and to write functions for it, it was written in [url=http://en.wikipedia.org/wiki/Pl/1]PL/1[/url] and now it is written in C++.

At the same time I was told that Micro Computers would be nothing more than fancy calculators and would never be able to perform complex computing tasks. Well your desktop or laptop computer is the descendant of the Intel 8080 or Motorola 6502 processor.

The computing world does not end with change but adapts to the change.

Microsoft said it would no longer support Windows XP! I am still downloading and installing Windows security updates! Also many large purchasers are still purchasing new computers with Windows XP installed or are allowed to install Windows XP.

[b][i]Are you very sure that it was 'discontinue" and not 'deprecate'"?[/i][/b] That's exactly the question I tried to get answered. Everyone agrees that SOAP is being deprecated (as are web-based reviews.) Some folks on the Adobe forums said that there was no plan to discontinue SOAP, but you read what the Evangelist wrote to me.

The Evangelist also wrote the following:

[b][i]Discontinuing support means Adobe will not add new features to the SOAP interface evolves. They may update the interface as serious issues evolve.[/i][/b] We don't need any new features. We're still using a customized variant of the SOAPCollabSample (sdkSOAPCollabSample.js) that was first released, I think, in Acrobat 6. Additional UI features that we need are implemented in a plug-in. IOW, all we need SOAP for is to upload and download annotations to and from our server (ASP.Net + SQL Server). Therefore, our bottom line requirement is the retention of the Javascript SOAP object as it is currently implemented, and that's all.

[b][i]I would expect SOAP will be available at a limited level for versions 10 and 11 and then it will be fully replaced by newer collaboration technology.[/i][/b] I would certainly hope that SOAP remains available at least that long if not forever. Keep in mind that SOAP is hardly an obsolete or even an outdated technology. It may not be bleeding edge anymore but it's still vibrant and important. [i]DDE?[/i] Obsolete, yet Adobe still supports it. [i]OLE automation?[/i] Outdated, yet Adobe still supports it. So, what's the problem with SOAP?

[b][i]How many computer languages have come and gone? What has happened to the applications written in those languages? When I learned SAS and to write functions for it, it was written in PL/1 and now it is written in C++. [/i][/b] My first language was RPG II (argh!) followed by Assembly, RPG III, BASIC, QuickBasic, FORTRAN, PASCAL, C (both Mac and Wintel), C++, Java, VB6, C#, VB.Net, and of course Javascript and VB Script, and maybe a couple of others I have since forgotten. (Do T-SQL and XSLT count?) The first rich client apps I wrote for our document review service were written in VB6 and they used ODBC to connect to the database; the current rich clients are written in C# and talk to the database using Web services through our web server, which handles all of the DB connections. So, as you might surmise, I have no problem adapting to change and rolling with the punches.

But I also subscribe to the adage: "if it ain't broke, don't fix it." And SOAP ain't broke.

I am the evangelist referred to in this post and would like to clarify some of my statements.

To clarify, the original question posed involved the future of a SOAP based repository for document reviews. "Browser Based Reviews" are not supported in Acrobat 9.0 and are disabled in Acrobat and Reader 9.1 and higher. An examination of the Repository comparison table shows that a SOAP based repository is only supported for "Browser Based Reviews", not Shared Reviews which were introduced in Acrobat 8 and is now the supported way of collaborative review and markup in Acrobat and Reader.

The Acrobat JavaScript SOAP object is alive and well, it is only the SOAP based repository for "Browser Based Reviews" which is no longer supported and that is only the case because "Browser Based Reviews" themselves are no longer supported.

So - Why disable "Browser Based Reviews"? This was a tough call for the team. The decision to move away from "Browser Based Reviews" was for both business and technical reasons. However, the primary reason was that "Browser Based Reviews" are.... Browser Based. Meaning, they required that the browser has the necessary APIs available to us. With the number of popular browsers increasing, this proved to be unmanageable and difficult to support. Shared Reviews are browser independent making them more flexible, the technology more sustainable, and more likely to provide the same user experience regardless of platform, brand of browser, or browser version.

While "hoyawildcat" is correct in pointing out that Acrobat 7 and Acrobat 8 work with the latest browsers on Windows, it is also true that Acrobat and Reader do not work with FireFox on the Mac and requires a few changes to Safari on Mac Snow Leopard to work. Adobe is committed to, wherever possible, providing a consistent experience across all platforms we support. Obviously, there are limitations to that but it is a primary design goal even if the execution isn't perfect all the time. Because Shared Reviews are not dependent on anything outside of Acrobat, these reviews work seamlessly across platforms, inside and outside of the browser.

As for my comment where I was quoted as saying "[W]e are a publicly traded company that makes business driven trade offs between what we'd like to do and what we can do with the resources we have at any given time. I'm sure you can understand."

Please understand - my comments were in response to a series of questions posed by "hoyawildcat" ending with "What am I missing here?". Here's the full text of my response is just below....

What's missing is the fact that we are a publicly traded company that makes business driven trade offs between what we'd like to do and what we can do with the resources we have at any given time. I'm sure you can understand.

This decision isn't about SOAP, it's about browser dependencies. We are not in a position to pour engineering resources into significant features in Acrobat that are dependent on browser APIs which could, and have changed thus breaking our product. It's just that simple.

All of the questions I was replying to were purely technical in nature. I was expressing that there are practical and business considerations in addition to the technical.

As for the final line "I wouldn't bet the farm on "Shared Reviews." - That's actually good advice and advice that I shared with "hoyawildcat" during our email exchange. Shared Reviews leverage RSS and Acrobat JavaScript. This is the preferred way of doing collaborative reviews in Acrobat today, and for the foreseeable future, but technology does change... and quickly. Adobe is actually better than most technology companies as far as backward compatibility goes. Eventually, we will need to replace Shared Reviews with something else, count on it... but it won't be anytime soon. When disabling an existing technology, Adobe will communicate this fact and typically give developers at least one, usually two complete product cycles to migrate their solutions - that's around two to four years of time to adopt the new technology.

I hope this helps clarify my comments.

Joel,

Thank you for the clarification, but I am still very confused by the following statement:

What precisely does this mean? The repository is on OUR server; therefore Adobe has no influence over what we do with it. So, I presume you mean that Adobe is discontinuing support for certain Javascript objects, methods, and/or properties that are used to upload and download annotations to and from our repository. If so, which ones?

Net.SOAP?

Collab?

Collab.addAnnotStore?

Collab.setStoreSettings?

Collab.defaultStore?

Any of the other Collab methods and properties?

What about annot store functions that we implement on the client in a folder-level .js file?

this.enumerate = function(sorted)
this.complete = function(toComplete)
this.update = function(toDelete, toAdd, toUpdate)

In short, it would be [u]very[/u] helpful if you could be specify precisely which Javascript objects, methods and properties will be dropped by Adobe so that we can estimate the extent to which we will have to modify our document review service, which we have built around this technology (i.e. do a damage assessment).

Thanks,

Bill

hoyawildcat,

Shame on you for taking the full statement response to your questions and posting only a portion of it here on this forum. By purposely taking out your "What am I missing" question, and the "What's missing is" first part of the reply you completely changed the context and are misleading readers here.

You have the right be upset (and maybe rightfully so), but I find the fact that you posted communication between you and an Adobe employee bad enough- the fact that you took it out of context, reprehensible.

Dimitri
WindJack Solutions
www.windjack.com
www.pdfscripting.com

Dimitri,

You don't know what you're talking about.

My exchange with Joel involved 17 emails over the course of six days. What I posted here were the most relevant statements from those emails.

I could have simply posted the entire email thread, but that included a lot of background information about how we use Javascript SOAP. What I was seeking were answers; I didn't want to point fingers and name names. Would it have been better had I paraphrased his words rather than quoting them directly? Wouldn't you accuse me of being misleading then? I was trying to [u]avoid[/u] being misleading.

I did not know (and certainly do not believe) that correspondence between me and an Adobe employee is supposed to be confidential. There is no NDA. I tried to get clarification on these issues directly from Adobe, and when that resource dried up with my questions still unanswered, I posted messages to this and other forums, in the hope of getting some definitive answers out of Adobe, or perhaps to get other people to join the fray. At the moment, I'm still waiting for those definitive answers from Adobe.

Frankly, what I find astonishing (though perhaps not "reprehensible") is your siding with Adobe against a third party developer. Shame on you! After all, this is a technology that Adobe has evangelized since 2003 (Acrobat 6) if not earlier. The term "evangelized" has certain religious overtones -- reliance on "faith" over "reason." Well, I once had the faith but am now apostate. The kool-aid's given me a hangover.

Bill Erickson

Bill,

Please re-read my comment. I did not take any side, yours or Adobe's. I took issue with how you chose to communicate, or rather mis-communicate, your problem in a User to User forum.

Dimitri
WindJack Solutions
www.pdfscripting.com
www.windjack.com

Dimitri,

To repeat: You don't know what you're talking about.

Here's my email that immediately preceded Joel's "What's missing here..." reply:

Now, my final question, on its own, implies that Adobe would not continue to support SOAP, but in the context of the entire email thread, it should be obvious that I was referring to using SOAP for collaboration (as I make clear in the subject of this forum thread). Also, I probably should have used the term "outdated" instead of "obsolete"with respect to OLE automation. But the point of my "what am I missing" email was [i]why does Adobe support old technologies while dropping support for new ones, such as SOAP collaboration, that are still very viable, if not leading edge?[/i]

So, that is the context of my question about "What am I missing here?" And, frankly, I think I make a good point. SOAP is not obsolete, and, indeed, Adobe itself makes an excellent case -- in its Acrobat 9 SDK no less! -- for building a SOAP-based collaboration solution -- e.g. http://livedocs.adobe.com/acrobat_sdk/9.1/Acrobat9_1_HTMLHelp/Collab_ChoosingRepos.114.6.php

Now, in the hope of avoiding being accused again of misleading the readers, Joel [u]did[/u] point me to the note at the bottom of http://livedocs.adobe.com/acrobat_sdk/9.1/Acrobat9_1_HTMLHelp/Collab_Introduction.113.3.php

Unfortunately, I didn't realize that in dropping support for web based reviews, Adobe would throw out the baby out with the bathwater, esp. since Adobe extolled the virtues of SOAP-based collaboration elsewhere and throughout this Acrobat 9 SDK document.

Mybad.


Bill

So now that we know this, how can we replace the functionality of the browser based reviews? Shared reviews do not really work for us as we need folks to come to our web application, go into their review fill out information in our web app and comment on the PDF.

Suggestions?

Daniel

According to the Acrobat 9.1 SDK Help docs Browser-Based work flows are still supported.

JavaScript - > Developing Acrobat Applications Using JavaScript - > Review, Markup, and Approval - > Online collaboration essentials - > JavaScript-based collaboration driverhttp://livedocs.adobe.com/acrobat_sdk/9.1/Acrobat9_1_HTMLHelp/JS_Dev_RMA.77.10.php

I see no mention of the feature being deprecated or removed or in any way 'not supported'.

As a browser based comment repository is something my company is currently in the process of deciding to code, I would very much like an answer to weather or not this is supported now, or will be supported in the future, and if not fully removed then in what capacity?

A browser based SOAP service is the only service that will work for my corporation as we store sensitive documents for our clients and due to government regulations we can't just farm it out to Adobe and use their service.


Thanks in advance,
Josh

I believe this post deals with conjectures about the support for the SOAP object and commenting procedure in future versions to be introduced after version 9, the current version as of today.

Read the note at the bottom of http://livedocs.adobe.com/acrobat_sdk/9.1/Acrobat9_1_HTMLHelp/Collab_Introduction.113.3.php :

Adobe is notorious for not keeping its documentation up-to-date and in synch. However, I have been told by Adobe that the above "note" takes precedence over everything else that Adobe publishes in the SDK concerning browser-based reviews, which means that everything else in the SDK about SOAP-based collaboration is in doubt.

As I reported in my original post, Adobe strongly implied to me that in Acrobat 10 it would discontinue support for browser-based reviews in favor of "shared reviews," which I and others have discovered is not scalable to our needs -- 100s of reviewers, 1000s of documents, 10000s of comments, all managed by a single administrator. (We're now up to 98,000 comments entered by 183 users since 2006 on 9272 docs, and during the past month we've averaged 233 comments per day, including weekends.) Based on what you wrote, it sounds to me that "shared reviews" and "Acrobat.com" won't work for you either:

(We're a national nuclear lab and are therefore also subject to very strict government regulations.)

I have sought clarification from Adobe on what they will and will not support in Acrobat 10, in particular concerning "Collab.addAnnotStore" and all of the related "Collab" methods and properties (see my 2010-04-30 13:14:36 post in this thread), but Adobe has not responded to my queries. So, all we can do is wait until Adobe officially releases Acrobat 10. Consequently, my customer and I have no choice but to assume the worst: browser-based reviews will not work in Acrobat 10. We have therefore decided to reimplement SOAP collaboration in a plug-in, and we are making good progress in that regard. Needless to say, however, I hope that my pessimism proves unwarranted and Adobe does [u]nothing[/u] that will put our five-year-old SOAP-based document review service at risk, which we developed because of Adobe "evangelism dating back to Acrobat 6," but Adobe is mum on the subject.

Exactly.

So, what would you suggest we do concerning the future? Sit on our hands and hope that Adobe doesn't screw us, or make contingency plans?

Kindly keep in mind that we're talking about Adobe-based systems built around SOAP collaboration that have evolved over several years and cannot be replaced overnight.

I do not work for Adobe, so I will not speculate.

There are a number of built-in functions from Acrobat 3.0 that haver been replaced by better or more robust functions and the old code is still in the Adobe provided services. Look at the "AFParseDate' (obsolete) and the 'AFParseDateEx' functions.

Adobe probably will continue some current usage, but is not going to fix minor problems or further develop its functionality. How long this support will last is unknown.

Adobe is struggling and developing many new ways of interacting between programs and computers, so there is no way to determine what will develop.

You know we can't answer questions about future versions of Acrobat (or any other Adobe software), but it's eminently sensible to take the fact a feature has been permanently disabled as a cue to [u]stop using it as soon as possible[/u]. It's true of legacy multimedia, and of browser-based reviews. The product team don't turn things off for a joke - there's always a reason, and often it's a security issue that can't be fixed any other way.

Not only will switching to an alternate workflow (such as a plugin using SOAP) avoid problems with users having to turn a feature back on that Adobe has strongly suggested them not to, it means you don't have to care about the eventual removal of the disabled code from any future versions, be that now or in years to come.

If it turns out in the future that a gap appears where alternate pathways don't fully replace a feature, I'm sure it will be addressed. Adobe is working hard on collaboration and commenting across all product lines; but the needs of users evolve, as do the platforms they use. Sometimes we have no choice about dropping support for features that rely on external programs.

Just to be clear about our plans re: browser-based reviews.

When I said that we're assuming that Adobe will discontinue support for "browser-based reviews," I was using that term in the narrow sense that Adobe uses it in the SDK, i.e. their [u]current[/u] implementation of "browser-based reviews" using [i]Collab.addAnnotStore[/i], etc. We certainly hope that "discontinuing support for browser-based reviews" does not mean that users won't be able to add annotations through a browser. If at all possible, we intend for users to continue reviewing and marking up documents in a browser; we're just reimplementing the SOAP-based upload/download functionality and the Collab "annot store".

Unfortunately, at the moment, we still need to set [i]Collab.showAnnotToolsWhenNoCollab = true[/i] via [i]AFExecuteThisScript()[/i], because we can find no other way to expose the commenting toolbar in a browser. So, we hope that Adobe does not disable [u]that[/u] feature in Acrobat 10. However, our longer-term plan is to do all of this [u]without any Javascript whatsoever[/u], because we want to disable Javascript on user desktops in light of Acrobat's long history of Javascript-related security issues.

Incidentally, another reason we don't like "shared reviews" is that it requires embedded document-level Javascript, which my customer has ruled [i]verboten.[/i]

I was also using the term in that narrow sense. I can't be certain without testing, but don't imagine your proposed workflow using a plugin will have any major technical problems provided the plugin only accesses the network. There's a licensing agreement problem if the plugin is for [u]Reader[/u] and it "activates" commenting on a file that hasn't already been assigned extended rights though - an issue you should raise with product support directly. Plugins for Reader are restricted from re-implementing a feature that is normally only found in Acrobat.

To clarify - we have *not* said that "browser-based reviews and SOAP support" will be discontinued.

We have said that browser-based reviews *specifically* have been disabled by default in the current dot releases of Acrobat and Reader, and that application developers should take this change as a very strong indication to move away from a workflow that relies on browser-based reviews; not only because it requires users to turn the feature back on, but support cannot be guaranteed in future (either in terms of Acrobat and Reader, or in terms of the API links to newer web browsers). Given the security environment and constant streams of new browsers and operating systems tinkering with the traffic between the plugin, browser and server; it isn't reliable anymore, period.


There is a link on the AcrobatUsers.com homepage to register for the Acrobat and Reader 10 prerelease program - any developer planning to write plugins for Acrobat or Reader 10 should join so they can test their systems before rollout. The software is not yet ready for you to download, but registrations are being taken. I would be wary of investing a huge amount of effort into coding a specific data route until you have access to the beta and can understand what's been changed.

jacecoleman,

I presume that when Adobe said
they were referring to the current Acrobat implementation of SOAP-based collaboration. I think that's correct because the annots are constructed in the PDF with JavaScript and I don't believe it's possible to create a custom annotation with JavaScript, but I could be wrong about that.

However, there's no reason that you couldn't construct your custom annotation from within a SOAP-enabled plug-in using the PDF Library API (PDAnnot, etc.). In this approach, you [u]may[/u] still be able to construct all of the standard annots using Acrobat JavaScript, and then create your custom annot separately with the API, so you wouldn't need to reinvent the wheel on the standard annots. A cleaner approach, however, would be to create all of the annots in the plug-in using the API (i.e. without JavaScript).

The first version of my SOAP-enabled plug-in still relies on JavaScript to create the annots, which means it can't support custom annots. However, as I wrote earlier, I hope to eliminate [u]all[/u] JavaScript calls in a later version of the plug-in, which should make it possible to support custom annots.

Bill

Hi Daniel and Bill,

we are in the same situation, having developed a SOAP based solution, integrated in a PLM system.
Requirements regarding regulations for our review process are not that restrictive, because we are using it in an editorial process for manuals only. After the review of hundreds of so called page blocks , potentially done for each by several engineering people, the responsible editor will digitally sign the merged document befor long term archiving. I'm working for an Aerospace company in Germany.

Shared reviews would have been an option (WebDAV based), if anyone would have been able to tell us, what the name mangling algorithm is. The documentation and statemtents from Adobe regarding this were definitly wrong. So - no option and we decided to use SOAP.

From my point of view, talking about problems with browser API interfaces is nonsense, as other Adobe products like the Flash player don't have any problems to support different browsers. Maybe the different division of Adobe should improve their communication.

So it seems, the only solution for the future is to stay at a 9.0 level of Acrobat and then go with some other vendor. Since we're still using 6.0 for this stuff, we're not in trouble right now.

Better idea: join forces and set up an open source plugin project for the communication part?!

Cheers
Stefan

Btw:
SOAP based reviews are the only reason to buy and use more than the Reader, since we're are creating PDF/A files with a product of some other vendor. So if this function is not available in upcoming versions, we have no reason to purchase a Acrobat license at all.

Yes, I agree that Adobe's contention is bogus -- a red herring -- that the ever-changing browser APIs precludes Adobe from supporting browser-based reviews into the future. Frankly, I think that "explanation" insults our intelligence, but I can live with that. (I work for the government.)

I'm still hoping that Adobe will explain why it intends to drop its support of browser-based reviews, but I'm not holding my breath, because I don't think they have a good answer.

Amazingly, we have tested our browser-based document review service using Acrobat 8 on the Chrome browser, and it works like a charm. What is amazing is that Acrobat 8 was released in 2006 and Chrome in 2008, which means that Adobe must have anticipated the Chrome API [u]two years[/u] before Chrome was released. You have to hand it to Adobe for its prescience; in a peculiar way, it kind of justifies our faith in Adobe technology.

I, for one, would love to break free from the Adobe monopoly regarding browser-based reviews and go our own way, irrespective of Adobe's business decisions. (I suspect, but cannot prove, that Adobe thinks that browser-based reviews somehow threatens their nascent Acrobat.com franchise, which my customer simply cannot use because its documents are OUO or even more classified, which means its documents can't be uploaded to a public site, all of this quite apart from the technical shortcomings of Shared Reviews.)

Alas, if we use Acrobat in [u]any[/u] way, then we must genuflect to the Adobe Overlord, because Adobe can very easily block network access from Acrobat plug-ins simply because it has the power to do so (sound familiar?), which means [u]no SOAP[/u], as it were. So, we have to play nice and hope that Adobe will too.