One of ActiveRecord''s greatest strengthes is its fluidity. Change a col in your db, restart, wham!, new class. This type of behavior is great for *internal* code. But for published interfaces, it''s the exact opposite of what you want. Let''s say I have a calendar web app, and expose a web service - via ActiveResource - for you to hook in your local GUI app (or command line app, or complenetary web app, or whatever you use ActiveResource for): How would you feel if your GUI app broke every time I refactored? How would I feel if I couldn''t refactor because doing so will break all those GUIs? Thought so. A web service interface needs to be stable, hiding the implementation and any changes in it. It needs to be *decoupled* from changes ot the internal schema. Rails is built on _extraction_. It seems to me that ActiveResource - along with all the upcoming REST pixie dust - has been dreamt up before actually being used in succesful apps. Is there any publically available app exposing an ActiveResource api? Does it have any external clients? I''m all for REST, and I''d love to see a RESTful competitor to SOAP, but it needs to be stable, static, decoupled from internals, and discoverable via something like WSDL (yes, WSDL can be used for REST too.) I think the Rails community is the best posed to make it happen - but not like this. (I''ll end my comments by pointing out that I think Rails is great. I hope my constructive criticism is received in the spirit it''s intended.) -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Amazon estimates that > 50% of its Web services are accessed via REST. Seems like someone bought into it. On Dec 25, 2006, at 11:59 AM, Robert James wrote:> > One of ActiveRecord''s greatest strengthes is its fluidity. Change > a col > in your db, restart, wham!, new class. > > This type of behavior is great for *internal* code. But for published > interfaces, it''s the exact opposite of what you want. Let''s say I > have > a calendar web app, and expose a web service - via ActiveResource - > for > you to hook in your local GUI app (or command line app, or > complenetary > web app, or whatever you use ActiveResource for): > > How would you feel if your GUI app broke every time I refactored? > How would I feel if I couldn''t refactor because doing so will break > all > those GUIs? > > Thought so. > > A web service interface needs to be stable, hiding the implementation > and any changes in it. It needs to be *decoupled* from changes ot the > internal schema. > > Rails is built on _extraction_. It seems to me that ActiveResource - > along with all the upcoming REST pixie dust - has been dreamt up > before > actually being used in succesful apps. Is there any publically > available app exposing an ActiveResource api? Does it have any > external > clients? > > I''m all for REST, and I''d love to see a RESTful competitor to SOAP, > but > it needs to be stable, static, decoupled from internals, and > discoverable via something like WSDL (yes, WSDL can be used for REST > too.) I think the Rails community is the best posed to make it > happen - > but not like this. > > (I''ll end my comments by pointing out that I think Rails is great. I > hope my constructive criticism is received in the spirit it''s > intended.) > > -- > Posted via http://www.ruby-forum.com/. > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
<...>> Rails is built on _extraction_. It seems to me that ActiveResource - > along with all the upcoming REST pixie dust - has been dreamt up before > actually being used in succesful apps.<...> To me it seams that your troubles and doom scenario is more dreamt up :) Can you provide an example of refactoring which would break anything, assuming that public interface was more or less designed? Regards, Rimantas -- http://rimantas.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Rimantas Liubertas wrote:> To me it seams that your troubles and doom scenario is more dreamt up :) > Can you provide an example of refactoring which would break anything, > assuming > that public interface was more or less designed?Almost any database or class refactoring: * Rename a field * Rename a method * Move a field to an associated object * Change a method signature * Etc. Steve Ross wrote:> Amazon estimates that > 50% of its Web services are accessed viaREST. They have a stable interface. I''m all in favor of REST, mind you. What I don''t see working is a shapeshifting API made public. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 25, 2006, at 1:33 PM, Robert James wrote:> Steve Ross wrote: >> Amazon estimates that > 50% of its Web services are accessed via > REST. > They have a stable interface. I''m all in favor of REST, mind you. > What I don''t see working is a shapeshifting API made public.Your original question was "Is there any publically available app exposing an ActiveResource api?" While I didn''t answer that, what I did do was provide a publically available app that exposes a REST interface (as does YouTube, BTW). I don''t perceive WSDL is not a solution to changing APIs. An answer like "they have a stable interface" implies that there is some "pixie dust" solution to unstable interfaces. It''s true that Rails does auto-discovery of the implementation details of your app. It''s not so obvious that a Web Services client will need (or whether they should need) the same level of transparency down to the nuts and bolts. If you return a list of cities for a zip code, then your client doesn''t need to know much more than get http://myfineapp.com/geo/ cities/10012. What''s more stable than that? The tighter you couple, the more brittle things become and the more you''ll have to worry about refactoring. If you decide you have an incredibly cool new API you want to publish, then keep the legacy one for legacy clients. That''s what everyone did with DLLs, COM, CORBA, and pretty much everything else that involved consuming someone else''s code using established interfaces. No? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Steve Ross wrote:> If you return a list of cities for a zip code, then your client > doesn''t need to know much more than get http://myfineapp.com/geo/ > cities/10012. What''s more stable than that? The tighter you couple, > the more brittle things become and the more you''ll have to worry > about refactoring. If you decide you have an incredibly cool new API > you want to publish, then keep the legacy one for legacy clients. > That''s what everyone did with DLLs, COM, CORBA, and pretty much > everything else that involved consuming someone else''s code using > established interfaces. > > No?Steve - I''m with you 100% that REST APIs are excellent. ActiveResource is trying to do much more than that - it reflects on the fields of the table, just like ActiveRecord, and exposes them. Being that the API is just a reflection of the underlying schema, there *is* no way to keep the legacy API around. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> Steve - > I''m with you 100% that REST APIs are excellent. ActiveResource is > trying to do much more than that - it reflects on the fields of the > table, just like ActiveRecord, and exposes them. Being that the API is > just a reflection of the underlying schema, there *is* no way to keep > the legacy API around.Does it reflect on the fields of the table, or on the attributes of the model (which may be fetched from the DB table, but may be defined in the model itself). In the case you must change some field in db - why not just add a method to your model which maps old name to the new field. Is there anything I am missing what would not allow this? Regards, Rimantas -- http://rimantas.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/25/06, Rimantas Liubertas <rimantas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > Steve - > > I''m with you 100% that REST APIs are excellent. ActiveResource is > > trying to do much more than that - it reflects on the fields of the > > table, just like ActiveRecord, and exposes them. Being that the API is > > just a reflection of the underlying schema, there *is* no way to keep > > the legacy API around. > > Does it reflect on the fields of the table, or on the attributes of > the model (which > may be fetched from the DB table, but may be defined in the model itself).By default it reflects the attributes, but you can customize it with to_xml. For instance if you rename an attribute but want to keep the old one around, you can specify that. Check out the to_xml docs. And really, how often does your app change things around? Do you really like breaking your own app''s compatibility? For a real rails app that''s compatible with ActiveResource *right now*, check out Beast: http://beast.caboo.se/. Check out my intro article: http://weblog.techno-weenie.net/2006/12/13/taking-ares-out-for-a-test-drive But yes, ARes was dreamt up before being used in a site. A few of us in core started fleshing it out as we needed aspects of it. But, since it''s not really proven in production environments, it remains unreleased. Another thing: who says the xml in your app has to map to ActiveRecord? ActiveResource sees xml and posts it. It could easily work against a compatible php or python app too. -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Rick Olson wrote:> And really, how often does your app change things around?That''s the whole point of agile development - make it easy to change. If things don''t change, we really don''t need a lot of the magic Rails delivers.> But yes, ARes was dreamt up before being used in a site.Okay, here''s my challenge: Take any actively developed Rails based app that''s more than a year old. Typo will do, I believe. Check out the src from a year ago, and make any useful ActiveResource based API. It can do anything useful. Make a simple client to use it. (The client can''t depend on any of the app''s source. Best is to write it in a different language - that''s what Web Services are for.) Now, update to the latest src. Did the client break? If it does, than ActiveResource isn''t very useful. Again, I''m writing because I''m proud of what Rails has done. I feel that after such success, there''s a move to get into second system syndrome and out design the world. Rails'' success is based on extraction. Let''s not loose that. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
If you change your implementation that drastically, will the API still function as expected in the first place? Who goes around wantonly changing the database schema without making major enough changes that clients shouldn''t be updated? Even so, there are ways around what you''re talking about. The problem is that you want to hang on to legacy APIs while updating your code; thats not a "normal usage" so Rails/ActiveResource doesn''t address it. Why glop it up for everyone else just because a few people need to make it work the way you describe? I''d wager a good majority of developers won''t encounter something like you describe. And though it''s not directly handled, Rails/ActiveResource does, provide other, less easy ways to accomplish what you describe (just like ActiveRecord has ways to fit into a legacy DB). Most of them have been suggested here. I fail to see a problem here, but then again, I may not understand your whole situation. --Jeremy On 12/25/06, Robert James <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Rick Olson wrote: > > And really, how often does your app change things around? > > That''s the whole point of agile development - make it easy to change. > If things don''t change, we really don''t need a lot of the magic Rails > delivers. > > > But yes, ARes was dreamt up before being used in a site. > Okay, here''s my challenge: > > Take any actively developed Rails based app that''s more than a year old. > Typo will do, I believe. Check out the src from a year ago, and make > any useful ActiveResource based API. It can do anything useful. > > Make a simple client to use it. (The client can''t depend on any of the > app''s source. Best is to write it in a different language - that''s what > Web Services are for.) > > Now, update to the latest src. Did the client break? If it does, than > ActiveResource isn''t very useful. > > Again, I''m writing because I''m proud of what Rails has done. I feel that > after such success, there''s a move to get into second system syndrome > and out design the world. Rails'' success is based on extraction. Let''s > not loose that. > > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> Now, update to the latest src. Did the client break? If it does, than > ActiveResource isn''t very useful.If the client breaks, than the developers are doing a poor job. Making an external API is making a commitment to your users. If you want to make crazy schema changes now, just realize you''ll have to provide some backwards compatible way to access the old service. - Use XSL to transform the old XML to the new XML. - Take the hash data of the old XML hash and fill your recently modified models with it. Or, you could just deprecate it and provide an ajax widget (zing!) There''s nothing in ActiveResource that says the server has to tie the data directly to the model. -- Rick Olson http://weblog.techno-weenie.net http://mephistoblog.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/25/06, Robert James <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Rimantas Liubertas wrote: > > To me it seams that your troubles and doom scenario is more dreamt up :) > > Can you provide an example of refactoring which would break anything, > > assuming > > that public interface was more or less designed? > Almost any database or class refactoring: > * Rename a field > * Rename a method > * Move a field to an associated object > * Change a method signature > * Etc.This list of reasons is also why code libraries have flopped. wait............ You''re right, if you''re cavalier about making changes like the ones you listed above, then client code will blow up. That''s not how public libraries and APIs work though. You keep the API backwards compatible, so even if you renamed a field/method you would have the old one (and perhaps mark it as deprecated). I will agree that it can be dangerous because there are so many Rails developers that use the Rails magic without knowing anything about Ruby. But I think I probably wouldn''t find their APIs useful (nothing I couldn''t write in a couple minutes with script/generate), and I''d probably be scared to use their API for more reasons than them just breaking it. Pat --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
It seems the consensus on this list is that if you want to use ActiveResource, you have to give up making changes, refactoring, or agile development - or at least work very hard if you want to do so. To met, that defeats the whole point. Any bets on whether they''ll be even one succesful app in production within 12 months with heterogenous clients (that is, written by other developers, outside the source tree of the app, even in different lanaguages) consuming ActiveResource API''s? Anyone up for my earlier challenge? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 26, 2006, at 9:52 AM, S. Robert James wrote:> It seems the consensus on this list is that if you want to use > ActiveResource, you have to give up making changes, refactoring, or > agile development - or at least work very hard if you want to do so. > > To met, that defeats the whole point.I cannot imagine why anyone believes that. If you''re going to provide an API, the problem has to be pretty well understood, and the API is a contract of sorts. ActiveResource makes it easy to both provide and consume the API. Why would you see it as an impediment to progress?> Any bets on whether they''ll be even one succesful app in production > within 12 months with heterogenous clients (that is, written by other > developers, outside the source tree of the app, even in different > lanaguages) consuming ActiveResource API''s?Oh, heavens, I''m tempted to take that bet! Expect that I''m not so sure they''ll be consumed in other languages.,, Doesn''t everyone use Ruby for everything from now on? :-) -- -- Tom Mornini, CTO -- Engine Yard, Ruby on Rails Hosting -- Reliability, Ease of Use, Scalability -- (866) 518-YARD (9273) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> > It seems the consensus on this list is that if you want to use > ActiveResource, you have to give up making changes, refactoring, or > agile development - or at least work very hard if you want to do so. >I guess I didn''t make my point clear earlier. If you change your API, will clients still function the same? Or will you have to make special cases for them, regardless of what tools you use create the API? For example, say you build a webservice and change the name of a function or move a database table. Now you have to go back and change your code in the first place, correct? So, how is this any different than using ARes? Make a special case, move on with your life. New clients and those who can update will; those who won''t can be caught by the special case code. Even further, if you make huge sweeping changes, your clients are going to have to update anyhow (and I see changing database schemas as a pretty big change...). I fail to see the difference in effort here.> > Any bets on whether they''ll be even one succesful app in production > within 12 months with heterogenous clients (that is, written by other > developers, outside the source tree of the app, even in different > lanaguages) consuming ActiveResource API''s? >Done. I''m running our dorm security app on our campus here on Rails Edge. It uses ActiveResource and interfaces with a Python application I wrote last year and a Perl app (that used to interface with a Java application) that someone else wrote way before my time. It has about 1000-2000 users a day. What do I win for the bet? ;) --Jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> Almost any database or class refactoring: > * Rename a field > * Rename a method > * Move a field to an associated object > * Change a method signature > * Etc.This is where the misunderstanding lies. Active Resource is not tied to the model or the database in any way. It merely reflects on the XML returned. Yes, we have convenience methods like to_xml for Active Records, but that''s merely convenience. You can generate your XML any way you like. Remember, Active Resource is the client side of REST. What you do on the server side, to keep the XML returned stable, is entirely up to you and entirely orthogonal to the concerns of Active Resource. It seems what you have a beef with is ActiveRecord#to_xml. Which is fine. Keeping API XML consistent as the application evolves is an interesting challenge. It just doesn''t have anything to do with Active Resource. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> (I''ll end my comments by pointing out that I think Rails is great. I > hope my constructive criticism is received in the spirit it''s intended.)A second note on this. This is a false declaration of content. Like if I picked up a jar that said it contained sugar, but was full of vinegar. The label does not make the content sweet, regardless of the font size used. If you wish to provide "constructive criticism" then I''d recommend using a less flashy banner ("Why ActiveResource will flop...") and replace hasty conclusions with invitations to debate. That way you don''t even need a disclaimer saying that your vinegar is really sugar. The taste will make that self-evident. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/26/06, S. Robert James <srobertjames-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > It seems the consensus on this list is that if you want to use > ActiveResource, you have to give up making changes, refactoring, or > agile development - or at least work very hard if you want to do so.It seems like you made a statement and then took that as consensus, when the majority of developers here have disagreed with you. Any time you have a public API, you have to be careful about making changes. This doesn''t mean you can''t make them, but that you just have to be careful and keep your API backwards compatible. It''s really not that hard of a concept. Pat --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 27/12/2006, at 7:13 AM, DHH wrote:> If you wish to provide "constructive criticism" then I''d recommend > using a less flashy banner ("Why ActiveResource will flop...") and > replace hasty conclusions with invitations to debate. That way you > don''t even need a disclaimer saying that your vinegar is really sugar. > The taste will make that self-evident.That''s the biggest thing I''ve got out of this thread. Nice one. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
And of course you can get around that restriction by popping the word ''Beta'' somewhere on the accompanying web page. :-) Pat Maddox wrote:> This doesn''t mean you can''t make them, but that you just > have to be careful and keep your API backwards compatible. It''s > really not that hard of a concept. > > Pat--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Ouch. I appreciate that the point is well meant David, but it comes across a little harsh. The programmer community is not known for its articulation, and most do not have your skills in that area (and without question a lot of other areas as well). Isn''t it encumbent upon those ''in the know'' to re-read hasty conclusions and inflammatory subject lines as invitations to debate - particularly if there is any semblence of an ''attack'' on Rails Core developers? Otherwise the mildly inarticulate acolyte will feel crushed by the tutting and wagging of fingers of those they revere. And then they are lost to the debate and our community is poorer for it. NeilW DHH wrote:> If you wish to provide "constructive criticism" then I''d recommend > using a less flashy banner ("Why ActiveResource will flop...") and > replace hasty conclusions with invitations to debate. That way you > don''t even need a disclaimer saying that your vinegar is really sugar. > The taste will make that self-evident.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Robert James wrote:> How would you feel if your GUI app broke every time I refactored?This is a Frequently Asked Question regarding the interaction between Agile development and published interfaces. The answer is to apply more of the Agile development practices - specifically Customer Tests. Each feature your customer wants, you deliver it with a suite of Acceptance Tests that lock down the feature''s specifications. Done right, your customer should author these tests, or at least review them. So if your customer wants a web service, they get a set of tests specifying that web service''s published interfaces. You are now free to refactor all you like. If you break any test, you revert and try to refactor again. BTW "Refactor" doesn''t mean "code-and-fix with your design". It means "change the design while passing all its tests". Re-read all the verbiage about refactoring with that in mind. -- Phlip http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> Ouch. I appreciate that the point is well meant David, but it comes > across a little harsh.It was not meant to come off as "a little harsh", it was meant to come off as harsh. The good tone of this list, and other Rails community outlets, is valuable and precious and worth standing up for. It doesn''t take much more than good men to do nothing for that to deteriorate the way this original post started out. No technical discussion and no potential diamond debater in the rough is worth that. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I may be a little confused here, but bear with me. From my understanding, ActiveResource is the class to consume XML (client side) and ActionWebService is the server side. So how would ActiveResource break your GUI app, when it is not even used? It reflects on whatever comes back from response. Second, if you are talking about ActionWebService''s reflection capability messing up your API, shouldnt you also make sure that your refactoring works correctly? If i change a method on the API (by adding/changing a column or whatever), shouldnt I also make sure that the original API calls work (maybe throwing a Deprecation Error and letting the user know there is a new method). Isnt that how the RAILS framework is built in the first place? Example: Rails has now deprecated the form_tag, but i still use it and deal with the warning. (Before you guys jump on me about that, I already know i should be using form_for :) ) Eventually, i will use the new method, but it is my choice. Its not the framework''s fault that you broke a method. Personally, i love the reflection in all parts of the RAILS framework. I expect it to do that. And when the time comes to make changes, i will keep that in mind and code accordingly. peace --jake Robert James wrote:> One of ActiveRecord''s greatest strengthes is its fluidity. Change a col > in your db, restart, wham!, new class. > > This type of behavior is great for *internal* code. But for published > interfaces, it''s the exact opposite of what you want. Let''s say I have > a calendar web app, and expose a web service - via ActiveResource - for > you to hook in your local GUI app (or command line app, or complenetary > web app, or whatever you use ActiveResource for): > > How would you feel if your GUI app broke every time I refactored? > How would I feel if I couldn''t refactor because doing so will break all > those GUIs? > > Thought so. > > A web service interface needs to be stable, hiding the implementation > and any changes in it. It needs to be *decoupled* from changes ot the > internal schema. > > Rails is built on _extraction_. It seems to me that ActiveResource - > along with all the upcoming REST pixie dust - has been dreamt up before > actually being used in succesful apps. Is there any publically > available app exposing an ActiveResource api? Does it have any external > clients? > > I''m all for REST, and I''d love to see a RESTful competitor to SOAP, but > it needs to be stable, static, decoupled from internals, and > discoverable via something like WSDL (yes, WSDL can be used for REST > too.) I think the Rails community is the best posed to make it happen - > but not like this. > > (I''ll end my comments by pointing out that I think Rails is great. I > hope my constructive criticism is received in the spirit it''s intended.)-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---