[Ironruby-core] What is the status for providing support for Attributes?

Shri Borde Shri.Borde at microsoft.com
Wed Jul 29 13:46:41 EDT 2009


For the client side, will the “Dynamic Web Service Helpers” sample at the bottom of http://www.codeplex.com/IronPython/Wiki/View.aspx?title=Samples be of use? It ships as an IronPython sample, but is fully language-independent. Attached are two samples of how its used from IronPython. You can get the full sample from http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=8365#DownloadId=51539


From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Wednesday, July 29, 2009 1:44 AM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] What is the status for providing support for Attributes?

* removed rant as this isn't a philosophical discussion on WCF/SOAP/REST/JSON services :) *

For the client side you don't need attributes to generate a proxy for a WCF call at all and you can just use meta programming to create those for you.  Then on the server side there are few approaches you can use to host WCF services.  WCF allows you to virtually replace every bit and piece in its architecture with custom implemenations

One possible solution:
1. you can create a custom service host, instance provider and behavior that knows how to deal with ruby classes or DLR classes in general.
2. A custom operation invoker to select the method you want to call (that uses DLR infrastructure) + behavior to insert it in the wcf config
3. open-source it an the rest of the community will thank you for it :)
4. remove the need for xml configuration in default usage cases (totally optional but still a good idea :))

If you put a good dev on this he can have this done in a couple of days.

Only doing #1 will already get you hosting C# WCF services on the server, it even allows you to write your service in Ruby as long as you define the service contract in C#/VB/...

Attributes are a crutch used in the static world to annotate types with extra metadata. In ruby you typically use a class method invocation to provide that metadata because ruby doesn't break the inheritance chain when it comes to class level members. And in the WCF scenario I don't see the _need_ for attributes. I don't think we should be changing ruby to know about those static things but rather make the technologies aware of DLR languages and how to use them.

Please prove me wrong :)

disclaimer: I may have made things look easier than they actually are.
---
Met vriendelijke groeten - Best regards - Salutations
Ivan Porto Carrero
Blog: http://flanders.co.nz
Twitter: http://twitter.com/casualjim
Author of IronRuby in Action (http://manning.com/carrero)


On Wed, Jul 29, 2009 at 5:38 AM, Philippe Monnet <ironruby at monnet-usa.com<mailto:ironruby at monnet-usa.com>> wrote:
Jimmy,

Yes I was interested in attributes to be able to call WCF services (actually SOAP services) from Silverlight using Ruby.
With WCF support, I think that IronRuby will become a huge catalyst for Silverlight, especially for web enterprise developers.
At my work, SOAP services provide access to all our shared enterprise capabilities. All web apps use these services. Right now we use ASP.NET<http://ASP.NET> and are injecting more and more jQuery and JSON services to push the envelope on interactivity, richness and usability. I would rather use Silverlight but static languages are a drag on productivity for front-end development (don't get me wrong, I love C# for everything else - frameworks, services, etc.).
So far, in prototypes, I have had to create C# wrappers on top of the WCF/SOAP proxies but that makes it even more brittle when we have to evolve our service signatures. I would love to simplify web development and have a consistent dynamic language experience on the browser side. IronRuby would be perfect in this scenario and would lower the bar for Silverlight development. A good example of course is what is being done around Gestalt.

My perspective as an enterprise architect would be to include support for WCF in 1.0, but I totally understand the challenges of product scoping and shipping (I have experienced that for 5 years during the case tool years in the early nineties).
The work so far on IronRuby is spectacular in my opinion both from a technical perspective as well as a from a collaboration and openness perspective! So keep it up! :-)

Philippe

Jimmy Schementi wrote:
No, .NET Attributes are not planned for 1.0. IronPython 2.6 does not support it either, though they have a low level hook that could allow it to be implemented. I understant this blocks the usage of any frameworks which depend on Attributes (WCF), but in the grand scheme of .NET interop they are a feature that can wait until after 1.0.

If you disagree, please let us know; I'd really like all of you to agree that IronRuby is in a 1.0 state, not just the people who have @microsoft in their email addresses.

~Jimmy

On Jul 28, 2009, at 8:01 PM, "Philippe Monnet" <ironruby at monnet-usa.com<mailto:ironruby at monnet-usa.com>> wrote:
As you are getting near 1.0, is the support for attributes somewhere on the radar? It seems like the last time I saw an exchange on this was sometime in February.

Philippe
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core




________________________________






_______________________________________________

Ironruby-core mailing list

Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>

http://rubyforge.org/mailman/listinfo/ironruby-core




_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090729/3deb006b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: amazon.py
Type: application/octet-stream
Size: 2684 bytes
Desc: amazon.py
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090729/3deb006b/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flickr.py
Type: application/octet-stream
Size: 1914 bytes
Desc: flickr.py
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20090729/3deb006b/attachment-0001.obj>


More information about the Ironruby-core mailing list