Return to Question

Has anyone talked about creating an open source all-.net CD API for tridion? It seems like that would be a popular option for .net shops who aren't comfortable with the current API's ( Broker, DD4T) since they are .net wrapped around Java.

OK, so there is a good amount of logic in the CD jars that would have to re-written. But for an ASP.Net site that uses Sql Server for the Broker DB, why would anyone want to have a bunch of jars crammed into the stack? Yes, it works, but it at least complicates things.

UPDATE: Thank you for your all your comments. Here are my responses:

You would lose official Tridion support

• True, but thats the case with DD4T or the Razor mediator, right?

I think it's underestimated how long it will take to develop the same functionality there currently is.

• Agreed.

There's too much 'Not invented here' syndrom around it. Having a different API, will mean different quirks.

• No doubt about this. This mentality is an epidemic among software developers, but this case is different :)

You are not going to add anything to the current Broker API, where as DD4T added an MVC app at least.

• DD4t would have been a good project for a .net only API to have been created

I've actually seen team not want (.NET) dlls in their presentation servers

• Confused by this one. If I was a Java shop then this makes total sense, but you need the .net dll's to somewhere if you are going to use the Broker API diredctly from a .net app. I do like the second bullet point from Alvin. In a perfect world, I wouldn't want my web sites to be tied to any specific CMS, so the vendor agnostic approach is preferred. Maybe this is what the team's Alvin refers to are concerned about?

these .net shops do not need to deal with whatever java is deep under the hood.

• I dispute this, to some degree. I'm not saying it doesn't work, but the .net wrapped around Java approach adds complexity. And I've seen some problems related to this complexity.

...the Content Delivery side of SDL Tridion is OS independent, how that will be achieved?

• This isn't an issue with .net shops.

Why not re-write the whole Content Manager side as well along with CD?

• This comment was off on a tangent. My question was about the CD, not the CM. Flexilibilty on the CD side is one of the strengths of Tridion. You can do a lot of different things with CD without impacting the CM.

and add one more count in 1000+ vendor's list

• This is an interesting comment that could have it's own thread. But my short response is that I've never had any desire to write my own Database, IDE, Web Server, Spreadsheet, Text Editor etc, and I've used most of the major versions of each of those. But why then did I have the urge to write my own CMS after viewing what existing CMS Vendors have to offer? And I'm obviously not alone with that urge.

Has anyone talked about creating an open source all-.net CD API for tridion? It seems like that would be a popular option for .net shops who aren't comfortable with the current API's ( Broker, DD4T) since they are .net wrapped around Java.

OK, so there is a good amount of logic in the CD jars that would have to re-written. But for an ASP.Net site that uses Sql Server for the Broker DB, why would anyone want to have a bunch of jars crammed into the stack? Yes, it works, but it at least complicates things.

UPDATE: Thank you for your all your comments. Here are my responses:

You would lose official Tridion support

• True, but thats the case with DD4T or the Razor mediator, right?

I think it's underestimated how long it will take to develop the same functionality there currently is.

• Agreed.

There's too much 'Not invented here' syndrom around it. Having a different API, will mean different quirks.

• No doubt about this. This mentality is an epidemic among software developers, but this case is different :)

You are not going to add anything to the current Broker API, where as DD4T added an MVC app at least.

• DD4t would have been a good project for a .net only API to have been created

I've actually seen team not want (.NET) dlls in their presentation servers

• Confused by this one. If I was a Java shop then this makes total sense, but you need the .net dll's to somewhere if you are going to use the Broker API directly from a .net app. I do like the second bullet point from Alvin. In a perfect world, I wouldn't want my web sites to be tied to any specific CMS, so the vendor agnostic approach is preferred. Maybe this is what the team's Alvin refers to are concerned about?

these .net shops do not need to deal with whatever java is deep under the hood.

• I dispute this, to some degree. I'm not saying it doesn't work, but the .net wrapped around Java approach adds complexity. And I've seen some problems related to this complexity.

...the Content Delivery side of SDL Tridion is OS independent, how that will be achieved?

• This isn't an issue with .net shops.

Why not re-write the whole Content Manager side as well along with CD?

• This comment was off on a tangent. My question was about the CD, not the CM. Flexilibilty on the CD side is one of the strengths of Tridion. You can do a lot of different things with CD without impacting the CM.

and add one more count in 1000+ vendor's list

• This is an interesting comment that could have it's own thread. But my short response is that I've never had any desire to write my own Database, IDE, Web Server, Spreadsheet, Text Editor etc, and I've used most of the major versions of each of those. But why then did I have the urge to write my own CMS after viewing what existing CMS Vendors have to offer? And I'm obviously not alone with that urge.

Has anyone talked about creating an open source all-.net CD API for tridion? It seems like that would be a popular option for .net shops who aren't comfortable with the current API's ( Broker, DD4T) since they are .net wrapped around Java.

OK, so there is a good amount of logic in the CD jars that would have to re-written. But for an ASP.Net site that uses Sql Server for the Broker DB, why would anyone want to have a bunch of jars crammed into the stack? Yes, it works, but it at least complicates things.

UPDATE: Thank you for your all your comments. Here are my responses:

You would lose official Tridion support

• True, but thats the case with DD4T or the Razor mediator, right?

I think it's underestimated how long it will take to develop the same functionality there currently is.

• Agreed.

There's too much 'Not invented here' syndrom around it. Having a different API, will mean different quirks.

• No doubt about this. This mentality is an epidemic among software developers, but this case is different :)

You are not going to add anything to the current Broker API, where as DD4T added an MVC app at least.

• DD4t would have been a good project for a .net only API to have been created

I've actually seen team not want (.NET) dlls in their presentation servers

• Confused by this one. If I was a Java shop then this makes total sense, but you need the .net dll's to somewhere if you are going to use the Broker API diredctly from a .net app. I do like the second bullet point from Alvin. In a perfect world, I wouldn't want my web sites to be tied to any specific CMS, so the vendor agnostic approach is preferred. Maybe this is what the team's Alvin refers to are concerned about?

these .net shops do not need to deal with whatever java is deep under the hood.

• I dispute this, to some degree. I'm not saying it doesn't work, but the .net wrapped around Java approach adds complexity. And I've seen some problems related to this complexity.

...the Content Delivery side of SDL Tridion is OS independent, how that will be achieved?

• This isn't an issue with .net shops.

Why not re-write the whole Content Manager side as well along with CD?

• This comment was off on a tangent. My question was about the CD, not the CM. Flexilibilty on the CD side is one of the strengths of Tridion. You can do a lot of different things with CD without impacting the CM.

and add one more count in 1000+ vendor's list

• This is an interesting comment that could have it's own thread. But my short response is that I've never had any desire to write my own Database, IDE, Web Server, Spreadsheet, Text Editor etc, and I've most of the major versions of each of those. But why then did I have the urge to write my own CMS after viewing what existing CMS Vendors have to offer? And I'm obviously not alone with that urge.

Has anyone talked about creating an open source all-.net CD API for tridion? It seems like that would be a popular option for .net shops who aren't comfortable with the current API's ( Broker, DD4T) since they are .net wrapped around Java.

OK, so there is a good amount of logic in the CD jars that would have to re-written. But for an ASP.Net site that uses Sql Server for the Broker DB, why would anyone want to have a bunch of jars crammed into the stack? Yes, it works, but it at least complicates things.

UPDATE: Thank you for your all your comments. Here are my responses:

You would lose official Tridion support

• True, but thats the case with DD4T or the Razor mediator, right?

I think it's underestimated how long it will take to develop the same functionality there currently is.

• Agreed.

There's too much 'Not invented here' syndrom around it. Having a different API, will mean different quirks.

• No doubt about this. This mentality is an epidemic among software developers, but this case is different :)

You are not going to add anything to the current Broker API, where as DD4T added an MVC app at least.

• DD4t would have been a good project for a .net only API to have been created

I've actually seen team not want (.NET) dlls in their presentation servers

• Confused by this one. If I was a Java shop then this makes total sense, but you need the .net dll's to somewhere if you are going to use the Broker API diredctly from a .net app. I do like the second bullet point from Alvin. In a perfect world, I wouldn't want my web sites to be tied to any specific CMS, so the vendor agnostic approach is preferred. Maybe this is what the team's Alvin refers to are concerned about?

these .net shops do not need to deal with whatever java is deep under the hood.

• I dispute this, to some degree. I'm not saying it doesn't work, but the .net wrapped around Java approach adds complexity. And I've seen some problems related to this complexity.

...the Content Delivery side of SDL Tridion is OS independent, how that will be achieved?

• This isn't an issue with .net shops.

Why not re-write the whole Content Manager side as well along with CD?

• This comment was off on a tangent. My question was about the CD, not the CM. Flexilibilty on the CD side is one of the strengths of Tridion. You can do a lot of different things with CD without impacting the CM.

and add one more count in 1000+ vendor's list

• This is an interesting comment that could have it's own thread. But my short response is that I've never had any desire to write my own Database, IDE, Web Server, Spreadsheet, Text Editor etc, and I've used most of the major versions of each of those. But why then did I have the urge to write my own CMS after viewing what existing CMS Vendors have to offer? And I'm obviously not alone with that urge.

Has anyone talked about creating an open source all-.net CD API for tridion? It seems like that would be a popular option for .net shops who aren't comfortable with the current API's ( Broker, DD4T) since they are .net wrapped around Java.

OK, so there is a good amount of logic in the CD jars that would have to re-written. But for an ASP.Net site that uses Sql Server for the Broker DB, why would anyone want to have a bunch of jars crammed into the stack? Yes, it works, but it at least complicates things.

Has anyone talked about creating an open source all-.net CD API for tridion? It seems like that would be a popular option for .net shops who aren't comfortable with the current API's ( Broker, DD4T) since they are .net wrapped around Java.

OK, so there is a good amount of logic in the CD jars that would have to re-written. But for an ASP.Net site that uses Sql Server for the Broker DB, why would anyone want to have a bunch of jars crammed into the stack? Yes, it works, but it at least complicates things.

UPDATE: Thank you for your all your comments. Here are my responses:

You would lose official Tridion support

• True, but thats the case with DD4T or the Razor mediator, right?

I think it's underestimated how long it will take to develop the same functionality there currently is.

• Agreed.

There's too much 'Not invented here' syndrom around it. Having a different API, will mean different quirks.

• No doubt about this. This mentality is an epidemic among software developers, but this case is different :)

You are not going to add anything to the current Broker API, where as DD4T added an MVC app at least.

• DD4t would have been a good project for a .net only API to have been created

I've actually seen team not want (.NET) dlls in their presentation servers

• Confused by this one. If I was a Java shop then this makes total sense, but you need the .net dll's to somewhere if you are going to use the Broker API diredctly from a .net app. I do like the second bullet point from Alvin. In a perfect world, I wouldn't want my web sites to be tied to any specific CMS, so the vendor agnostic approach is preferred. Maybe this is what the team's Alvin refers to are concerned about?

these .net shops do not need to deal with whatever java is deep under the hood.

• I dispute this, to some degree. I'm not saying it doesn't work, but the .net wrapped around Java approach adds complexity. And I've seen some problems related to this complexity.

...the Content Delivery side of SDL Tridion is OS independent, how that will be achieved?

• This isn't an issue with .net shops.

Why not re-write the whole Content Manager side as well along with CD?

• This comment was off on a tangent. My question was about the CD, not the CM. Flexilibilty on the CD side is one of the strengths of Tridion. You can do a lot of different things with CD without impacting the CM.

and add one more count in 1000+ vendor's list

• This is an interesting comment that could have it's own thread. But my short response is that I've never had any desire to write my own Database, IDE, Web Server, Spreadsheet, Text Editor etc, and I've most of the major versions of each of those. But why then did I have the urge to write my own CMS after viewing what existing CMS Vendors have to offer? And I'm obviously not alone with that urge.