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

  • Hi Alvin. This here is so hidden away, it's slipped my attention entirely. Since this idea proposal I've acquired quite a bit of Java knowledge and did some deployer extensions on the side with other non-Tridion Java development. However, I haven't changed my mind. A .NET deployer is the way to go.

    Many Tridion customers I've worked for in the past wanted to use some forms of custom data stores on the delivery side, or at least, they would'd been better off with custom data stores instead of the non-performing one-size-fits-all Broker database.

    Extending the deployer would be a logical option for these customers. But since this requires Java skill, which the majority of Tridion developers don't have, most customers ended up with less obvious alternative solutions that usually lead to unpleasant consequences. A pity.

    If it was .NET instead it would have saved at least a few burnouts.

    And as Albert Romkes mentioned .NET Core is cross-platform. I assumed Tridion at some point will be migrated to .NET Core, and I thought the deployer would be the perfect first candidate, because it is one of the most isolated and self-contained modules of the Tridion suite.

Comment

  • Hi Alvin. This here is so hidden away, it's slipped my attention entirely. Since this idea proposal I've acquired quite a bit of Java knowledge and did some deployer extensions on the side with other non-Tridion Java development. However, I haven't changed my mind. A .NET deployer is the way to go.

    Many Tridion customers I've worked for in the past wanted to use some forms of custom data stores on the delivery side, or at least, they would'd been better off with custom data stores instead of the non-performing one-size-fits-all Broker database.

    Extending the deployer would be a logical option for these customers. But since this requires Java skill, which the majority of Tridion developers don't have, most customers ended up with less obvious alternative solutions that usually lead to unpleasant consequences. A pity.

    If it was .NET instead it would have saved at least a few burnouts.

    And as Albert Romkes mentioned .NET Core is cross-platform. I assumed Tridion at some point will be migrated to .NET Core, and I thought the deployer would be the perfect first candidate, because it is one of the most isolated and self-contained modules of the Tridion suite.

Children
No Data