Accepted, Not Yet Planned

See my comment and our interest in the use cases. There's likely a way to achieve the same goals with another extension point or implementers could try Java.

.NET content deployment module

A .NET content deployment module would be a very welcoming feature. This would have two main benefits.

1. The entire Tridion back-end is .NET. (Here I consider the content deployment module a back-end module) . Consistency in technology makes things easier to work with and to maintain.

2. A .NET content deployment module would invite many more people to build custom content deployment features.

Personally I am a .NET developer. I have always wanted to build custom content deployment extensions. However, with the current Tridion content deployment module I'm forced to use Java to do customization and Java skill is something I don't have, unfortunately. Building a custom deployer is therefore no option for me.

I think there are many who are in the same boat like I am. The number of Tridion .NET vs Java open source, and the questions asked on Tridion Stack Exchange do suggest this.

With a .NET content deployer Tridion would tap into a much bigger development audience, which is a good thing. It would be beneficial to both developers and Tridion. New ideas will emerge from this, no doubt.

Hoang Chu
Parents

  • Thanks for the suggestion Hoang. The deployer is very likely to stay Java for awhile since it has to support multiple platforms.

    With the Web 8 architectural split to Content Interaction Services (CIS) and Content Interaction Library (CIL) changes and with OData even before that, approaches to "Content Delivery" can be a bit more agnostic. For example, we're already seeing customers and implementers opt for things like client-side templating and personalization. They use a variety of approaches from storage extensions, "OData extensions," or delivery-side "content models" (as seen in DXA and DD4T implementations).

    In the future we'll likely continue to expand these options, but no plans for the deployer for now.

    But what use cases would you be interested in? You're thinking of the ability to extent publishing/deployment in .NET? Would other languages would be interesting for not just deployer extensions, but other parts of Content Delivery like the ADF (JavaScript/TypeScript/other)?

Comment

  • Thanks for the suggestion Hoang. The deployer is very likely to stay Java for awhile since it has to support multiple platforms.

    With the Web 8 architectural split to Content Interaction Services (CIS) and Content Interaction Library (CIL) changes and with OData even before that, approaches to "Content Delivery" can be a bit more agnostic. For example, we're already seeing customers and implementers opt for things like client-side templating and personalization. They use a variety of approaches from storage extensions, "OData extensions," or delivery-side "content models" (as seen in DXA and DD4T implementations).

    In the future we'll likely continue to expand these options, but no plans for the deployer for now.

    But what use cases would you be interested in? You're thinking of the ability to extent publishing/deployment in .NET? Would other languages would be interesting for not just deployer extensions, but other parts of Content Delivery like the ADF (JavaScript/TypeScript/other)?

Children
No Data