[Pharo-project] Seaside Book: Chapter 17, Serving Files
bschwab at anest.ufl.edu
Sun Mar 25 23:55:22 EDT 2012
I am probably missing something too<g>, but dynamically serving the documents is EASY, and that message should get out. The app in question originally ran on a server. At first, that was a way to get around my lack (at the time) of good file synchronizing on Linux - I have long since ported to Pharo a tool that I have use for years so that it runs on Linux. That makes it easy to move files from one machine to another (basically between desktop and laptop).
Having the system on a server offered the option for others to see the data, but they never used it. IT policies became problematic (or at least scary), and it is simply easier for to run it locally, so I took that plunge. The system has security features that make little sense now; I might remove them some day.
When it ran on a server, I simply generated urls for the full text articles. At present, serving the files dynamically "just works" and does it w/o the need to think about servers and URLs. It is a nice solution that I think deserves mention along with FileLibrary and other methods.
From: pharo-project-bounces at lists.gforge.inria.fr [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Francois Stephany [tulipe.moutarde at gmail.com]
Sent: Sunday, March 25, 2012 11:23 PM
To: pharo-project at lists.gforge.inria.fr
Subject: Re: [Pharo-project] Seaside Book: Chapter 17, Serving Files
I probably miss something in the use case but why don't you simply serve
that static content with Kom or Zinc ?
On 25/03/12 18:29, Schwab,Wilhelm K wrote:
> Clearly, I can't put hundreds of megabytes in a FileLibrary, and I have
> no interest in configuring a static web server for something that (sadly
> or not) runs locally on multiple machines, with data synchronized via
> what amounts to an rsynch clone and ever-growing flash sticks.
More information about the Pharo-dev