3

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.

Improve this question
3
  • "Not wanting the dlls" is basically customers wanting to avoid any "software" on their sites for maintenance, training, or independence from vendors. I've seen this even more on Java setups (when trying to follow architectural discussions). But the three concerns are: 1) any setup (license, dlls, jars, and config) for each-and-every server in a possibly very large Web farm, 2) the learning ramp for Web developers, and 3) any jar/war version conflicts and upgrades. Okay so last one isn't .NET-specific. :-)
    – Alvin Reyes
    Commented Apr 10, 2013 at 16:04
  • Interesting point on why we expect out of CMS's. And yeah, we're getting a little off-topic. :-) The strength and possibly challenge with Tridion is it's pretty wide open to do or extend what you want on the CM or CD side. The product's CD .NET API uses jars. You can remove this complexity by rewriting a large part of the CD functionality (in an unsupported way), but complex isn't necessarily hard (paraphrasing Bart). Can we take the discussion to twitter, blogs, or maybe Linked-In?
    – Alvin Reyes
    Commented Apr 10, 2013 at 16:12
  • I found a valid reason to want this... windowsazure.com/en-us/services/web-sites - Azure won't let you run Java on their Websites solution. Other than that, can't think of another one.
    – Nuno Linhares ♦
    Commented Aug 15, 2013 at 19:54

5 Answers 5

Reset to default
15

I see a lot of reasons not to do it:

  1. You would lose official Tridion support for the CD side of things.
  2. I think it's underestimated how long it will take to develop the same functionality there currently is.
  3. There's too much 'Not invented here' syndrom around it. Having a different API, will mean different quirks.

Other than that, yes I agree that the current setup using netrtsn an xmorgt.dll and a whole bunch of jar files in a .Net app is not the best idea.

(And yes, over the years I also wanted to rewrite CD functionality, but I'm happy I didn't do that in the end ;) )

Improve this answer
2
  • 3
    Realized I wasn't adding anything more than what you just said, so ^this.
    – Nuno Linhares ♦
    Commented Apr 9, 2013 at 19:31
  • totally agree with this indeed, plus what is the added benefit of it, sure the jars seem out of place in a .Net app, but functionality wise you are not going to add anything to the current Broker API, where as DD4T added an MVC app at least.
    – Bart Koopman
    Commented Apr 10, 2013 at 6:31
7

The reason that java is wrapped in .net is because java offers the concept of build once, run anywhere. So it makes sense to base it on java, and for .net simply wrap it instead of rewriting the whole API.

As far as .net shops who aren't comfortable with java modules, it's a moot concern because SDL fully supports this fuctionality and these .net shops do not need to deal with whatever java is deep under the hood.

Improve this answer
7

OK, think I digested this enough to pull in my own comments...

I am pretty sure you're not the first one to think of this (and I am even more sure some people actually started writing this). The obvious challenge for any unofficial project here is:

  • Support. You won't believe how many people will NOT use DD4T or the PowerTools because these are not supported.
  • Keep the drum beating. How do you cope with Tridion's changes, how quickly can you adapt to the new releases? (this is linked to the previous topic, as customers wouldn't be able to upgrade the CM until this CD stack would have been updated)
  • What do you really gain over, for instance, using OData as your content layer?

DD4T is not supported, as you mention, but the way it accesses Tridion content is supported. If there would be a bug in, for instance, DCP retrieval, then this bug is on Tridion's court to be fixed, not on the "community". Even if the community could fix it faster (SDL does have a strict support process that it must follow when fixing issues), customers would probably prefer knowing that it will be fixed.

I guess my main concern about it is upgrade-ability. If you look at the Tridion databases between releases, it has always changed (sometimes more than others). It is a fair assumption to expect this will continue to be the case, perhaps even more in the future with all the Dynamic stuff I want to fit into CD :)

Other than that, sounds like a fun project. Will it be successful? Most of the customers I talk with will not sacrifice support, and judging by the reactions here, this is also true for most implementers.

Improve this answer
7

"Why would anyone want to have a bunch of jars crammed into the stack?"

I've actually seen .NET teams not want (3rd-party or vendor-specific) dlls in their presentation servers, with the hesitation around vendor-specific APIs and/or a "dependency" on its database. So it might be one of:

  • .NET teams use the Content Delivery API, get it installed, and account for the jars in whatever build process they have OR
  • .NET teams prefer their own existing format, framework, or vendor-agnostic approach (XML, JSON, or some other existing text-based format)

SDL Tridion also has the Content Delivery Web Service to keep features like dynamic linking but remove (actually just move) the storage database dependency. Some Tridion knowledge is still needed, but the CD Web Service follows a standards-based approach with OData and the learning curve is less proprietary. "No API" might be more appealing than recreating the CD API.

Edit: noted that the point on dlls was indeed focused on 3rd-party vendor-specific dlls. In-process APIs still seem popular but many integrations happen in the Web Application or client-side using REST APIs.

Improve this answer
1
  • Excellent answer Alvin!
    – David Forster
    Commented Apr 17, 2013 at 10:10
2

What about robustness and Inter-operability of SDL Tridion being used across different OS? The documentation said the Content Delivery side of SDL Tridion is OS independent, how that will be achieved?

If you are trying to say doing this (Re-inventing the whole wheel for CD) just for a specific business reason and for a specific scenario - Why not re-write the whole Content Manager side as well along with CD and add one more count in 1000+ vendor's list - And your thought is not unique, many people are doing that and this actually have resulted in more than 1000+ CMS system in the market with their own Pros and Cons

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.