rubyonrailsin

So what, I wonder, would be involved in setting up a Heroku of
Radiant. A server with a no-write policy? A cadre of people to
maintain. Some capital to buy the hardware...

Thing I don't get is that heroku does host Radiant. Am I missing
something? Actually haven' put radiant on Heroku in ages.

A Heroku of
> Radiant would be most welcome to me, as well :-)
> ~ Alexis
> =================
> Alexis Masters, author
>
>
>
> On Mar 22, 2010, at 11:10 AM, Jason Garber wrote:
>
> This is a slightly old thread, but as one of the competitors Scott
> mentioned, I'd like to say, "Somebody, please put me out of business!" :-)
>  I only hosted Radiant sites for clients because there was no other option.
>  I would immediately switch all my clients to someone else's service if it
> was affordable, let me choose a package of extensions, and had easy
> import/export!  It's not a big moneymaker unless you refine Radiant hosting
> to a cheap, yet reliable, customizable, and scalable commodity.  Somebody
> needs to be the Heroku of Radiant! :-)
> -Jason
>
> On Mar 17, 2010, at 12:04 AM, M. Scott Ford wrote:
>
> Chris,
> I would also love to see some of the details behind how you implemented
> this. However, in the interest of full disclosure, I should mention that I
> am working on building a service that would compete with your small business
> web site service[1]. And from my casual browsing, it looks like I am not the
> only one[2][3]. I won't hold it against you (nor do I think that anyone else
> will) if you decide to keep the details of your implementation closed to the
> public.
> Jim,
> I still have to prove out my concept using the tools that I have mentioned.
> I would prefer to have at least a working proof of concept before adding
> anything to the wiki. But when I am at that stage, I will be sure to put
> something up there. Right now, I am leaning towards building a separate
> project to house this functionality. I think this is more in line with
> radiant's "no fluff" design goal, and I think that multi-site capabilities
> will be useful to more than just radiant users.
> -Scott
> [1]: http://sbmsuite.com/products/make-a-free-website
> [2]: http://radiantmachine.com/
> [3]: http://radiantcmshosting.com/
> On Mar 16, 2010, at 9:39 PM, Jim Gay wrote:
>
> I'd love to see this on the wiki if either of you have time to drop it in
> there.
> On Mar 16, 2010, at 5:02 PM, Chris Rankin wrote:
>
> Much of this functionality, I'm already doing with my application
> SBMSuite.com which is built using Radiant.
> When I create a site it's initially a subdomain of sbmsuite like
> scott.sbmsuite.com, but you can change that to scott.com whenever you want.
> I'm using apache+passenger to handle all request and it's all running of a
> single instance of Radiant. And I just use custom "roles" in my application
> to enable/disable extension per user.
> It works pretty good for me. Is that what your trying to do?
> On Tue, Mar 16, 2010 at 4:56 PM, M. Scott Ford <scott@vaderpi.com> wrote:
>>
>> Hello all,
>>
>> Ugh. I am doing it again, but more reading has lead to more information.
>> It looks like pancake[1] and proxy_stack[2] provide even more of what we
>> would need.
>>
>> One of the features that I would like to see in a multi-site
>> implementation is the ability to allow users to use their own domains.
>> proxy_stack provides the perfect way to do this. Let me present an example.
>>
>> Let's assume that we use warden for authentication and the
>> Rack::Session::Cookie middleware will be used for keeping track of sessions.
>> So we'd create a pancake configuration that looks like this: (source[3]).
>>
>> Pancake.stack(:session).use(Rack::Session::Cookie)
>> Pancake.stack(:auth).use(Warden::Manager) do |manager|
>>  manager.failure_app = FailStack
>>  manager.default_strategies = :password
>> end
>>
>> And then we have two client sites installed in a "/sites" root, and each
>> root points to a full radiant installation with a different set of
>> extensions for each client. The configuration for that would look something
>> like this. (Warning: I have not run this code.)
>>
>> SiteStack < Pancake::Stack
>> SiteStack.router do |r|
>>  r.add("/sites/:client") do |env|
>>    require "sites/#{env['usher.params'][:client]/config/environment"
>>    r.use Rails::Rack::LogTailer
>>    r.use Rails::Rack::Static
>>    ActionController::Dispatcher.new
>>  end
>> end
>>
>> Okay. That is all great, but how do we send "www.customer.com" to
>> "www.host.com/sites/customer". Based on my reading, it looks like we can
>> create a config.ru for each customer, and tell the rack-enabled webserver to
>> serve up that rack config whenever a request is received for
>> "www.customer.com". With apache+passenger you would create a "VirtualHost"
>> with a "ServerName" set to "www.customer.com" and with a "DocumentRoot" that
>> points to the public folder below the directory where the config.ru is
>> located "/var/www/clients/customer/public". That config.ru file will look
>> something like this. (I have not tested this either!)
>>
>> class ::ClientProxy < ProxyStack
>>  configuration.proxy_domain = "www.host.com"
>>  configuration.proxy_port = 80
>>
>>  before_proxy do
>>    client_name = "customer"
>>    # prepend "/sites/customer" to the request path before
>>    # it is forwarded to "www.host.com"
>>    request.path = "/sites/customer/#{request.path}"
>>  end
>> end
>>
>> run ProxyStack.stackup
>>
>> Does that make sense?
>>
>> Thanks,
>> -Scott
>>
>> [1]: http://github.com/hassox/pancake
>> [2]: http://github.com/hassox/proxy_stack
>> [3]:
>> https://gist.github.com/542e8b01412fe4a682bc#file_my_stack_middleware_example.rb
>>
>>
>>
>> On Tuesday, March 16, 2010 2:57pm, "M. Scott Ford" <scott@vaderpi.com>
>> said:
>>
>> > Hello again,
>> >
>> > I hate responding to myself, but it looks like warden[1] and
>> > url_mount[2] would be
>> > a good starting point for this, especially if radiant can be modified to
>> > rely on
>> > rails_warden[3] for authentication. We just need to write a rack
>> > application that
>> > uses warden and url_mount to handle "sites" or child rack applications.
>> >
>> > [1]: http://github.com/hassox/warden
>> > [2]: http://github.com/hassox/url_mount
>> > [3]: http://github.com/hassox/rails_warden
>> >
>> > Thanks,
>> > -Scott
>> >
>> > On Tuesday, March 16, 2010 1:58pm, "M. Scott Ford" <scott@vaderpi.com>
>> > said:
>> >
>> >> Hi all,
>> >>
>> >> I thought I would introduce a wild idea I had this morning while
>> >> thinking about
>> >> multi-site implementations. One reason that I have not tried to use any
>> >> of the
>> >> existing multi-site extensions is I want to have really fine grained
>> >> control
>> >> over
>> >> the gems and radiant extensions that are loaded for each site. (If
>> >> there is a
>> >> way
>> >> to control this with the existing multi-site extensions, then please
>> >> let me know
>> >> how.)
>> >>
>> >> Radiant itself already handles controlling the extensions and gems
>> >> loaded during
>> >> startup. What if we added another layer to that logic, and created an
>> >> extension
>> >> that knows how to do the same thing but for site? So basically, Radiant
>> >> core
>> >> would
>> >> just load the multi-site extension, and then every site would be what
>> >> we now
>> >> consider a Radiant instance. (If that makes any sense.)
>> >>
>> >> Another way to imagine this is to think about the multi-site
>> >> functionality
>> >> becoming the parent of Radiant core, instead of trying to fit a
>> >> multi-site
>> >> extension inside of Radiant (either directly in core or through
>> >> extensions).
>> >>
>> >> I am not all that familiar with the core code-base, yet, so I am not
>> >> sure if
>> >> this
>> >> is possible, but I thought I would pontificate and see what others
>> >> think.
>> >>
>> >> Now that I have typed all of that out, though. It is starting to sound
>> >> to me
>> >> like
>> >> these features might be best implemented as a rack middleware that
>> >> Radiant can
>> >> play nicely with. The middleware would own just sites and users, but
>> >> radiant
>> >> would
>> >> own pages, layout, snippets, etc...
>> >>
>> >> I imagine that this would be useful to others in the Ruby community (if
>> >> it has
>> >> not
>> >> already been done), and it would make it possible to have some sites
>> >> that run
>> >> rails apps, like radiant, others that are simple sinatra apps, and
>> >> others that
>> >> are
>> >> instances of any other rack-based web solution.
>> >>
>> >> Thoughts?
>> >> -Scott
>
> --
> Radiant CMS Dev Mailing List
> Post: radiantcms-dev@googlegroups.com
> Unsubscribe: radiantcms-dev-unsubscribe@googlegroups.com
> Group Site: http://groups.google.com/group/radiantcms-dev/
>
> --
> Radiant CMS Dev Mailing List
> Post: radiantcms-dev@googlegroups.com
> Unsubscribe: radiantcms-dev-unsubscribe@googlegroups.com
> Group Site: http://groups.google.com/group/radiantcms-dev/
>
> --
> Radiant CMS Dev Mailing List
> Post: radiantcms-dev@googlegroups.com
> Unsubscribe: radiantcms-dev-unsubscribe@googlegroups.com
> Group Site: http://groups.google.com/group/radiantcms-dev/
>
> To unsubscribe from this group, send email to
> radiantcms-dev+unsubscribegooglegroups.com or reply to this email with the
> words "REMOVE ME" as the subject.
>
> --
> Radiant CMS Dev Mailing List
> Post: radiantcms-dev@googlegroups.com
> Unsubscribe: radiantcms-dev-unsubscribe@googlegroups.com
> Group Site: http://groups.google.com/group/radiantcms-dev/
>
> To unsubscribe from this group, send email to
> radiantcms-dev+unsubscribegooglegroups.com or reply to this email with the
> words "REMOVE ME" as the subject.
>

--
Radiant CMS Dev Mailing List
Post: radiantcms-dev@googlegroups.com
Unsubscribe: radiantcms-dev-unsubscribe@googlegroups.com
Group Site: http://groups.google.com/group/radiantcms-dev/

To unsubscribe from this group, send email to radiantcms-dev+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.