> On Aug 11, 2017, at 2:34 AM, Colin Law <clan...@gmail.com> wrote: > > On 10 August 2017 at 13:36, fugee ohu <fugee...@gmail.com> wrote: >> >> >> On Thursday, August 10, 2017 at 3:01:06 AM UTC-4, Colin Law wrote: >>> >>> On 10 August 2017 at 07:50, fugee ohu <fuge...@gmail.com> wrote: >>>> One of my apps drives the others and stores pictures that the others use >>>> Both apps are on the same server How do i build a link to the image on >>>> the >>>> other app? >>> >>> You could use image_tag possibly. >>> >>> Colin >> >> >> how do i get above / ? > > Good point, you will have to arrange the upload to save to a location > visible to both servers, or accessible via another server, and do the > download link manually. > > Colin
There's many ways to get this to work, and depending on how your server(s) is/are architected, some are more elegant than others. In one application I built, there are three separate VPS hosts: database, admin, and public. Admin and public have the same NFS share mounted to each of them, with admin able to write to it, and public only able to read from it. The NFS share is defined in my file upload gem (Dragonfly) as the place where files are written. Dragonfly is somewhat unique in how it manages files (everything is proxied through a Rack app, never hosted directly through Apache/Nginx) so this means I don't have to have that NFS directory in the app's public/system/whatever path. But even if I wanted to allow direct httpd hosting of uploaded images, I could do that through the Apache configuration file, by aliasing a folder from /mount/nfs/share/whatever into public/system/images, for example. https://httpd.apache.org/docs/2.4/urlmapping.html#outside So that's an extreme example, brought about by having these apps on different (quasi-physical) servers. If you were hosting them on different virtual hosts on the same server (real or virtual), then your task is a lot simpler. Forget about the NFS mounts, and just configure your Web server to include the same directory, as above, and ensure that only one app is writing into that folder, and both are sharing a single database, so that the apps don't get confused. And I've completely overlooked S3 (or any of its various clones), which is sort of a giant share-point in the sky. If you use Fog or another cloud storage adapter, you can treat S3 as you would a local folder, and two or more servers can be configured to use the same S3 "bucket" at the same time. With UUID primary keys, you don't even need to coordinate the databases. As far as building a link goes, my apps assume that only one app is doing the writing, and the other one is read-only, so they share a database. Building a link is in the normal Rails manner, based on an ID. But if you had two independent apps that didn't share anything, you would need to build a bridge between them. One could advertise the images it has available through an API, and the other could use that API to periodically update a local cache of what images are available, for example, and what their addresses are, and use those directly. You would build an image tag with the src set to //other.host.dom/path/to/image.jpg rather than pretending it was on your local server. In the end, your solution will depend entirely on what your needs are. In my example above, I needed to support a team of editors, who could write things and add metadata to them and approve them, and a largish audience who were read-only on the things that were complete and "published". You might get some more focused solutions for your problem if you can articulate why you have separated these concerns. Walter -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/4351B338-862E-48A8-A95D-ADC061730E03%40wdstudio.com. For more options, visit https://groups.google.com/d/optout.
