Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > Author: resplin

Following the successful release of Alfresco Content Services in 2017, we have been planning our next round of innovation. In this blog post, we share some of our plans so that you can prepare for the next release and provide feedback. At the end you will find a table summarizing the actions you should take.


Even though we refer to Alfresco Content Services, most of this information also applies to Alfresco Community Edition.

There are three overriding architectural goals for upcoming releases of Alfresco Content Services (ACS):


  • Improve integration across the Alfresco Digital Business Platform - encompassing products such as Alfresco Process Services and the Alfresco Application Development Framework. One of these planned improvements is a shared authentication system that supports additional modern protocols such as OpenID Connect. This improved integration will make it easier for Alfresco Content Services customers to benefit from the power of Alfresco Process Services when their use case requires it.

  • Provide a containerized deployment option that can be hosted on a range of infrastructure, both on-premises and by cloud providers such as AWS. These containers will also be portable between deployment environments such as dev, test, and production.

  • Further enhance the REST API to allow advanced customizations to be completed outside of the repository Java process, including APIs for batching requests and subscribing to system events. Integrations using the REST APIs are easier to maintain and upgrade than customizations within the repository.


These goals will require some significant architectural changes to the Content Repository, and so we expect the next release to be a major version, Alfresco Content Services 6.0, which we plan to release in 2018. You will see these changes begin to enter Alfresco Community Edition immediately.


In order to make these improvements, we need to change some features of the product that you might be using. Specifically, we want to make sure you are aware of the following plans:


  • Installation Bundles: Customers have asked us to reduce the amount of effort necessary to deploy Alfresco Content Services (ACS) in a production configuration. The ACS installers will be replaced with Docker containers, using Kubernetes and Helm. This deployment technology allows us to better define a standard production configuration while giving greater flexibility to our customers as they deploy into their environments.

  • Web Application Servers: As part of providing a containerized cloud-ready deployment, we will be removing the need to manage a separate web application container. Instead, configuration will be injected into the Docker container, reducing the effort required to setup, secure, and manage the application. In the next release, we will no longer support Alfresco Content Services deployed within J2EE web application servers such as JBoss, WebSphere, and WebLogic. Over the long term, we are considering embedding the web application server within the repository and making the content repository directly executable. As a result, it is likely that support for deploying into a separate Tomcat web container will be dropped in a future release.

  • Solaris and DB2: As we focus on the most widely used deployment platforms, we will be dropping support for the Solaris operating system and IBM’s DB2 database.

  • CIFS an NTLMv1: Due to security vulnerabilities in the protocols, we will be removing the ability to access Alfresco Content Services as a shared network drive using CIFS / SMBv1 and the ability to authenticate using NTLMv1. We recommend that customers needing shared network drive access use our AOS WebDAV when using Windows clients and our standards-compliant WebDAV when using non-Windows clients. Customers should also use Kerberos instead of NTLMv1 for SSO. We will continue to improve our implementations of WebDAV and Kerberos.

  • Legacy Solr: ACS 6.0 will leverage the advanced capabilities of Solr 6. Previous versions of Solr will no longer be used—Solr 1 will be removed from the product, and Solr 4 will be deprecated and remain in the product only to support upgrades. No functionality will be lost upgrading to Solr 6, but there are some different defaults affecting the way locale is handled that will require minor adjustments in customizations.


In addition, we plan to remove the following capabilities:


  • Alfresco Process Services Share Connector: Advanced content and process applications can be built with superior user experiences using process and content components from the Application Development Framework.

  • Repository Multi-Tenancy: The multi-tenant capability of the Content Repository will only be supported as part of an OEM agreement and we are likely to remove multi-tenancy from Alfresco Community Edition. The support of multi-tenancy in Alfresco Process Services remains unchanged.

  • Encrypted Node Properties: This capability provides a label for properties that are managed by client code and is used internally in modules provided by Alfresco. With the release of Alfresco Content Services 6.0, it will be considered part of the private API. Custom clients can achieve the same capability by using a Blob or Base64 String property and managing the encryption of the content within those properties.

  • CIFS Shortcuts: Alfresco Content Services’ CIFS implementation provided Windows Explorer shortcuts for ECM tasks. These will be removed along with support for CIFS shared network drives. We do not currently plan to move them to the WebDAV implementation.

  • Meeting Workspace and Document Workspace: These Share site types are not supported by recent releases of Microsoft Office, and so will be removed.


With the release of Alfresco Content Services version 6.0, the following features will continue to be available but are deprecated, and you should expect them to be removed in a future version:


  • Some Share Features: We will gradually simplify Share to focus on the most commonly used capabilities by removing the following lesser-used site components and dashlets: site blogs, site calendars, site data lists, site links, and site discussion forums. These use cases are better met with dedicated interfaces, either through integration with third party applications or through custom development.

  • Web Quick Start: Web Quick Start provides an add-on to Alfresco Share that demonstrates how to build a website on top of Alfresco Content Services. Though customers are welcome to continue using Web Quick Start, we will not be enhancing this product. There are many ways to use the Alfresco Digital Business Platform to deliver content to the Web, and we would be happy to discuss your specific needs with you or point you to a partner.

  • Alfresco in the Cloud: As the market for content collaboration technologies has evolved, we are evaluating replacements for Alfresco in the Cloud ( We will offer different synchronization solutions to supersede Alfresco Cloud Sync to As a result, we are no longer adding new functionality to that service. As our new products mature, we will reach out to the customers who are using Alfresco in the Cloud to outline the replacements and possible timelines.


We also make the following recommendations to help those building applications on top of Alfresco Content Services to prepare for future releases:


  • The versioned REST API for ACS covers a wide range of use cases, and is preferred over in-process APIs for extending Alfresco Content Services. Integrations and customizations that use the REST API are easier to integrate into your own development processes and are easier to maintain when upgrading ACS.

  • In order to make it easier to design, deploy, and maintain custom workflows, in a future release we will be providing a platform-wide workflow service using Alfresco Process Services (powered by Activiti). This will replace the use of embedded Activiti for custom workflows. Future custom workflows will be implemented external to the Content Repository and will leverage the REST APIs of Alfresco Content Services. To be easily upgradable, new custom workflows should make local REST API calls in order to avoid using the in-process APIs.

  • ACS workflows are intended to automate the management of content items within the Content Repository and APIs for custom workflows will continue to be available with subscriptions to Alfresco Content Services. A subscription to Alfresco Process Services (APS) is required for advanced process management use cases which is used for collecting, disseminating, integrating and coordinating information across an organization.

  • Though we continue to improve and maintain Share, we recommend that custom applications be built with the Application Development Framework (ADF). ADF components make it easier to assemble and maintain custom applications.


Thank you for the feedback you have previously given on our products which have informed these changes. We think you will appreciate how these changes will allow us to evolve Alfresco Content Services to meet the needs of your organization both now and in the future. If you are a customer, and have any questions, please reach out to your Customer Success Manager. If you are using one of our open source products and want to engage in the discussion, feel free to comment on this post. We look forward to continuing the conversation with you.




The Alfresco Team


Table Summarizing Changes and Guidance

Architecture Change



Improved REST APIs

Use the REST APIs instead of the in-process APIs.


An eventual move to a platform workflow service

Custom ACS workflows should use REST calls to the Content Repository when possible.


Use APS for process management across the organization.





Simplify the Share UI

Integrate with 3rd party applications or develop custom interfaces.


Containerized deployment

Transition your deployment from the installers toward container technology.

6.0 release

Executable content repository

Move away from separate web application servers.

6.0 release

No support for Solaris

Migrate to a supported different OS.

6.0 release

No support for DB2

Migrate to a supported database.

6.0 release

No support for CIFS or CIFS shortcuts.

Use WebDAV.

6.0 release

No support for NTLMv1

Use Kerberos.

6.0 release

Replace Solr 1 and Solr 4

Upgrade to Alfresco Search Services powered by Solr 6.

6.0 release

Discontinue the APS Share Connector

Leverage the Alfresco Development Framework.

6.0 release

Repository Multi-Tenancy only for OEMs

If you need multi-tenancy, talk to your Customer Care Representative about your use case.

6.0 release

Encrypted Node Properties

Use a Blob or Base64 String property.

6.0 release

Removal of Meeting Workspace and Document Workspace site types

Use standard collaboration sites in Share.

6.0 release

Removal of some Share features: site blogs, site calendars, site data lists, site links, and site discussion forums

Develop a dedicated interface or use one provided by a third-party.

Post 6.0

Phasing out of Web Quick Start

Transition to another web delivery platform.

Post 6.0

Phasing out of Alfresco in the Cloud

No action needed at this time. We will contact you when there is a timeline you should be aware of.

Post 6.0


Moving from SMB to WebDAV

Posted by resplin Employee Nov 3, 2017

This long blog post explains how we are determining the future of shared network drive support in Alfresco Content Services. Specifically, we are considering dropping support for using the SMB protocol and instead increasing our investment in WebDAV for these use cases. We want to explain our reasoning and seek your feedback.


Analysis of the Problem

Alfresco has long worked to make the power of enterprise applications available to users who don't want to understand all the details of an ECM or BPM system. Early in the product's life, Alfresco added to the Content Repository the ability to be accessed as a shared network drive so that knowledge workers could receive the benefits of ECM while continuing their habit of "throwing everything in the Z: drive". We ended up implementing this capability three separate times: the CIFS dialect of SMBv1 in our JLAN module, standards compliant WebDAV, and the Windows specific WebDAV implemented in our AOS module. But the broad adoption of this capability has made it worthwhile.


Microsoft recently announced the end-of-life of SMBv1, including the CIFS dialect implemented by Alfresco. This protocol was the main exploit vector for the recent round of cryptolocker attacks. We cannot recommend our customers use this protocol, so we have been evaluating other options. You can see some of our conversations on this topic in the thread Re: SMB2 / SMB3 server support.


That conversations mentions a number of ways to implement SMBv3 which we investigated: upgrading our current implementation, using 3rd party open source libraries (there aren't any mature implementations of the server), implementing a storage back-end for Samba, and using proprietary libraries. Recognizing that the effort involved in implementing SMBv3 would slow down our progress on the other priorities described on our Content Repository Roadmap 2017, we also looked at alternatives ways to meet the same use cases.


WebDAV is an obvious choice to replace SMB, as our implementation is mature and it is widely used by our customers. It is also more robust than SMB when used on high latency networks such as when deploying the Content Repository in a cloud environment like AWS, which is an increasingly common use case. In many ways, WebDAV is a better fit for ECM use cases than SMB, which is intended to be used by high performance filesystems. Customers who attempt to use ACS as a file server are sometimes disappointed as a content repository makes a different set of trade-offs from a file server; it has many more capabilities but lower total throughput. Specifically, a file server uses SMB to allow mid-file access and high performance operations by exposing raw file handles to client applications, but this is not possible when the content is encrypted, is stored in an object store like S3 or Centerra, or is stored in a cheap high-latency infrequent access storage tier.


Many of the use cases where customers have expressed a preference for SMB over WebDAV require high frequency mid-file access. These use cases are not suitable for pulling directly from an content repository because they don't allow it to perform ECM functions. Instead, customers should synchronize the desired content to the client machine and back to the repository when the file is finished being used. Our proprietary Desktop Sync Server offers this capability, and is one of many solutions provided by both Alfresco partners and the open source community that can be used for this purpose.


Though our analysis suggests that WebDAV is an adequate replacement for SMBv1 in most use cases, we wanted to hear from a larger set of customers.



We sent a survey to 150 customers who have previously indicated that they use either the CIFS or WebDAV shared network drives, and 52 responded. Important findings included:


  1. WebDAV is already used more widely than CIFS.
  2. The ACS Windows Explorer shortcuts available through CIFS are not as widely used as expected.
  3. Concerns with SSO access to shared network drives. NTLMv1 is also insecure, and the survey showed that Kerberos is much more widely used.


We specifically asked customers why they don't use WebDAV in every circumstance, and a few key reasons surfaced:


  1. Concerns about performance: WebDAV does not perform as well as CIFS on a local network. Part of this performance is due to the mid-file access that CIFS can provide, but we believe there is room for optimization in our implementation which will help address this concern.
  2. Concerns about compatibility: Some applications, such as Adobe products, struggle when accessing large files over WebDAV. One reason why CIFS performs better for these applications is the direct file handles for mid-file access that we discussed earlier. The second reason is that our CIFS implementation intelligently handles the file shuffling these applications do during write operations. We plan to port this shuffling from our CIFS implementation to our WebDAV libraries.
  3. Multiple customers raised a concern that the Windows 255 character limit impacts WebDAV folders. Our plan is to use repository shortcuts to make it easy to mount deep folders on short paths.
  4. The largest file that can be shared with WebDAV is 4GB. Desktop Sync is a better way to work with such files, as working with a 4GB file over WebDAV would require many round-trips of the full file.


For those who are interested, here are the detailed results from the survey. Note that the questions are usually multi-select, so results do not add to 100%. Also, there was an "Other" option where respondents could enter additional text, which accounts for the last few results in many questions. I apologize for the truncation in the answers.


Truncated options: Shared network drive, Custom application, An official Alfresco Connector, Publication through a web portal or public web site, Other: From Jive or Liferay Portlets.

Truncated options: Engineering Designs, Graphic Design, Other: all types of research files.


The Future

As a result of this analysis and research, we intend to take the following actions:

  • It is expected that Alfresco Content Services 5.2 will be the last release with a CIFS implementation. Along with retiring CIFS, we will be retiring NTLM and the ACS Windows Explorer shortcuts. Instead we will recommend the use of WebDAV and Kerberos.
  • We will compensate for the identified shortcomings in WebDAV by:
    • Implementing smart file shuffling with WebDAV to increase compatibility with commonly used applications.
    • Making it easy to deep-link into the Alfresco Content Repository over WebDAV to avoid issues with path length.
    • Focusing on improving WebDAV performance at scale.
    • Continuing to improve the performance of Desktop Sync when used with very large files.
  • We are also considering SAML support for shared network drives, though that work is not currently scheduled and won't be available in the next release.
  • If there is sufficient customer demand for an SMBv3 implementation, we will reconsider that development effort. In order to lower the cost of development, it is likely that we would leverage a proprietary 3rd party library. As such, any future SMBv3 functionality is not expected to be part of our open source offerings.


I look forward to discussing the implications of this change in the comments below.

With the recent release of Alfresco Community Edition 201602, and Alfresco One 5.1, the latest version of Alfresco is ready for broad adoption. The 5.1 release has exciting new capabilities that will benefit organizations large and small, and we want to be clear about which capabilities are in which product edition.


This lengthy blog post explains how we decided which innovations to open source, and which we reserved for our Alfresco One subscribers. It illustrates how we have been applying the principles laid out by Alfresco founder John Newton when he reiterated Alfresco’s commitment to a strong open source product. By being transparent in our approach to open source, we hope that people who adopt Alfresco Community Edition will have confidence that it will continue to meet their needs.

For those who want to skip the rationale, here are the highlights:

    • The technology for Smart Folders is included in Community Edition and is completely open source.




    • Records Management for Community Edition continues to improve, but we are also creating a proprietary Records Management module for Alfresco One that will contain advanced features tailored to specific use cases.

This post focuses on how we make decisions about differentiation between our open source and proprietary products. There are lots of additional improvements to Alfresco Community Edition and Alfresco One that are beyond the scope of this post. Also beyond the scope of this post are the new features of Activiti and our mobile apps.

Objectives of Alfresco Community Edition

Alfresco Software is a business with ambitious goals for growth and impact. Open source is an important part of our strategy because of the value it provides to customers, how it contributes to adoption of our products, and how it increases our rate of innovation.

We have four specific objectives for Alfresco Community Edition:

    • Be the default ECM solution, increasing ECM competence throughout the industry.


    • Foster product innovation as we bring the best contributions back into the product.


    • Spread community contributions to benefit all users of the product.


    • Be an on-ramp to our paid offerings.

There is a natural tension between some of these objectives. We want broad adoption of Community Edition, which requires a full featured product that everyone wants to use. But in order to continue to invest in innovation, we need to maintain a healthy business which requires us to reserve some value exclusively for our paid offerings. Openness is a core value at Alfresco Software, and we want to be transparent in how we draw this line so that people can participate in our open source community with accurate expectations.

Since Alfresco’s first statement about our open source strategy in 2009, we have been clear that Alfresco One is the product we design for scaled and production environments. But we are also proud that we produce an open source Community Edition product that is not crippled or unstable. Clearly defining the target audience for Community Edition helps us to make product design decisions. We have adopted an “open core” model that is distinctive because we do not limit the “open core” to a library or platform that is only useful to developers. Our “open core” is a collection of ECM use cases that we preserve as open source and which becomes the foundation of our proprietary products.

Defining Alfresco Community Edition

We have identified three use cases for Alfresco Community Edition:

    • Small deployments where the advanced capabilities of Alfresco One Enterprise Edition are not necessary,


    • Evaluation of new features and exploration of Alfresco on new projects,


    • Companies who want to keep ECM completely in-house, and have the IT expertise committed to expanding, customizing, maintaining , and collaborating around the open source product.

We believe that if we design for the first use case, we will also meet the other use cases while preserving the incentive to convert to our paid products as deployments grow and customers realize value from the platform.

So when evaluating a feature for Alfresco Community Edition, we ask if it meets the following criteria:

    • Important for deployments of less than approximately 100 users,


    • Single-server,


    • Non-mission critical, since we do not offer formal support,


    • Consists of a horizontal capability with broad applicability.

Examples of horizontal capabilities include document management, collaboration, case management, compliance, and business process management

We further reserve functionality for Alfresco One that fits one of these criteria:

    • Proprietary connections and 3rd party plugins. If our product is being used alongside other products that require subscriptions, we should share in the value of the solution. Examples include integration with MSSQL, Oracle DB, Amazon S3, Kofax, and Centera.


    • Scalability, high availability, advanced security, and related configuration. These capabilities are important for enterprise use cases running at enterprise scale. Examples include clustering, high performance content transformations, the LDAP configuration assistant, JMX administration, and encryption at rest.


    • SaaS products and 3rd party plugins that increase our delivery costs on a per-client basis.


    • Specialist applications and niche use cases, such as Contract Management and Media Management.


It is important to recognize that none of these criteria are absolute, rather they are intended to guide our thinking around product design. Specifically, we have no intention of limiting the product to 100 users, as we understand that any artificial restriction to an open source product would just be removed. Choosing a specific number helps us in our calculations around pricing and support, and it orients us when discussing features. Our research shows that the overwhelming majority of Alfresco Community Edition deployments are well under 100 users, and those deployments are usually successful with that product. When deployments grow larger, or when an organization can not tolerate even a short disruption to their systems managing content and processes, then the importance of advanced features, expert support, and Certified Partners grows. Of course some smaller deployments will still need to buy Alfresco One to meet their specific needs, and some larger deployments will be inclined to invest the effort to continue with Alfresco Community Edition as the basis of their ECM strategy.

In order to make Alfresco Community Edition be the default content repository in the industry, we need to market it broadly and aggressively. Organizations of all types should see immediate value in Alfresco Community Edition, and be free to evaluate Alfresco One when their use cases grows to the point that they can realize the value in the offering.

Specific Innovations in Alfresco 5.1

The above criteria leads us to include in Alfresco Community Edition features like Smart Folders and Custom Model Management. These are broad capabilities that are important for a wide variety of ECM solutions. We are proud to open source these innovations.

The latest release of Alfresco Community Edition also includes a significant upgrade to our integration with Microsoft Office through the replacement of the implementation of the SharePoint Protocol provided by the VTI module with the newer Alfresco Office Services (AOS) module.  AOS is a complete reimplementation of the latest standard of the protocol, and includes significant testing to ensure interoperability. It will be easier to maintain and improve as Alfresco and Microsoft Office continue to evolve.

Integration with Microsoft Office is important for broad adoption of our product because it is broadly applicable, including in small deployments. But it is also a proprietary integration that we can use as the foundation for advanced niche capabilities targeted at large enterprises. This leads us to include AOS in Alfresco Community Edition as an optional proprietary module so that most users can benefit, but those who want a pure open source platform are not required to use it. For those who want to collaborate around an open source implementation of the SharePoint protocol, the VTI library is still available under the LGPL and we are willing to assist you in your efforts.

The AOS functionality is currently identical between Alfresco Community Edition and Alfresco One. Though the source is not available, AOS is included as a default module in Alfresco Community Edition. This is a change from our previous stance toward ubiquitous proprietary software, but we think it is the right approach in a world of cloud services and bring-your-own-app IT.

A Product Tailored to Its Intended Use Case

The criteria we use to define Alfresco Community Edition might also lead us to remove some features. As an example, in Alfresco 5.0 we deprecated the social publishing framework. It was a proprietary integration and served a niche use case, but we didn’t consider removing it until we were faced with the challenge of keeping these integrations current with the various publishing services. Now it is part of our proprietary Media Management module where the investment in maintenance and development is tied to the specific customers who purchase it.

Similarly, we have discussed whether multi-tenancy or replication really belong in Community Edition, as these are not single server uses cases that are important in small installations. This is a good illustration of how we think about product design, but we don’t currently have plans to remove these capabilities.

In our analysis of Alfresco Community Edition, we did not identify any other existing features that we felt should be removed based on the use cases we are targeting.

The Future of Records Management

Some of the customers of our Records Management module have been asking us for advanced features which are tailored to specific governmental use cases and that don’t apply to smaller deployments. We have decided to make these part of a new Alfresco  Records Management  module that is intended to work on licensed versions of Alfresco One. Specifically, these features are:

    • Security clearance management and property controlled access,


    • Management of classified content, including classification guides and declassification review (necessary for the DOD5015.02 certification for classified records),


    • Delegation of RM administration, which is useful in the management of very large scale deployments,


    • Capstone email compliance, which is an email archiving capability designed to meet the requirements of the U.S. Federal Government,


    • Verifiable wipe and data destruction as required by certain national governments.

In order to implement the new security clearance capability, we will deprecate the “supplemental markings” feature, and the related “lists of values” administration screen that were previously part of the open source release. We don’t think this impacts our open source community, as these features were not widely used. We plan to remove them and only maintain our proprietary security clearance capability that takes an entirely different approach to managing security clearance markups. The open source module will also gain a clearer way of managing Transfer Locations.

The next release of the Records Management module for Alfresco Community Edition will be compatible with Alfresco Share 5.1 and the 5.1 Platform. It will contain bug fixes and the improvements to the APIs and core services that are necessary to implement the new Enterprise-only features. As we better understand the use cases around these new features, some aspects of them might move into the Community RM module in future releases.

We will continue to enhance the Records Management module for Alfresco Community Edition, and it will be the core of the Enterprise RM module. We are working to move our RM development to git so that it is easier for you to track our enhancements and easier for you to contribute through pull requests. We are increasingly taking this approach with projects like Activiti, Aikau, and our mobile applications. We plan to incorporate these improved practices into our development for Alfresco Community Edition and Alfresco One.


We are working to focus Alfresco Community Edition on its target market, while also producing features for advanced use cases that can drive the Alfresco One business necessary for us to continue to invest in our products. As John Newton said in 2009: we aim to be guided by principles that are fair and accountable, as we believe that our model will result in a stronger open source product.

By clarifying the role Alfresco Community Edition plays in our product portfolio, we saw the need to increase our pace of open source innovation. In the six months before the Generally Available (GA) release of Alfresco 5.1, we released Alfresco Community Edition four times. Two of those releases incorporated major new features. We completed more QA testing on Alfresco Community Edition 201602 than for any previous release. And now that the product is out the door, we are excited to start pushing our next round of development to the public source tree.

I look forward to hearing your thoughts and feedback on our efforts, and to working with you in the Alfresco open source community. If you want to continue this conversation in person, join my session at BeeCon. We have many more innovations to share with you in the months and years to come.

In a game-changing move aimed at increasing adoption among young, hip, Internet-native developers, Alfresco today released a CMIS client library for the popular brogramming language LOLCODE.

'Everyone who follows me on Twitter knows that I spend most of my waking moments searching for the best lolcats on teh internetz.' said Peter Monks, Alfresco's Director of Hirsute Affairs. “But when I stumbled across LOLCODE and saw the enormous adoption it’s now enjoying, I realised that we needed to ensure that Alfresco’s leading content management services were fully leveragable in lulz critical applications.”

LOLCATS who want to nom your spec.

These additions to the LOLCODE language are already garnering critical acclaim from hipsters and humans alike, with powerful new constructs including:

Language Construct

CMIS Operation


Enable the LOLCMIS capabilities

PLZ OPEN <serverVar> '<CMIS service document URL>'? [PRETTY PLZ WIV '<username>' ['<password>']??]

Connect to a CMIS compliant repository (optionally with a user name and/or password) and retrieve the CMIS service document

IM IN YR <serverVar> LISTING YR <repoVar>

List the repos within a CMIS Server

IM IN YR [<repoVar>|<folderVar>] LISTING YR <contentVar>

List the contents of a repo’s root folder or folder


Download content

MAEK [FIEL|FODLR] <contentVar> IN <folderVar> WIV <properties> [AN <contentLength>:<content>]

Create a new file or folder using the properties and (optional) content

OOPS! FIX <contentVar> WIV <properties> [AN <contentLength>:<contentData>]

Update an existing file or folder using the properties and (optional) content

DO NOT WANT [<folderVar>|<contentVar>]



Bulk deletion


Policy management

Here is a sample program that lists the contents of the default repository in a CMIS server, demonstrating just how idiomatic these new capabilities are:

HAI 1.2


BTW Load the new CMIS library


BTW Attempt to connect to the CMIS server

PLZ OPEN SERVR ''? PRETTY PLZ WIV 'admin' 'admin'??


    BTW Find the default repo


      BOTH SAEM REPO['default'] AN WIN, O RLY?

        YA RLY

          BTW List all contents of the default repo


            VISIBLE 'U HAS A ' STUFF['cm:title']

          IM OUTTA YR REPO

      NO WAI






Alfresco is currently in discussions to contribute the code to the Apache Chemistry project - stay tuned for further announcements.

Filter Blog

By date: By tag: