static image files

> Ohh, I think I already asked for that several times and even proposed
> possible solutions, like to give more power to WAStringLibrary and to
> make it a subclass of a WAFileLibrary class so that CSS, JavaScript
> and Images can go toerether and reference each-other... but I got no
> answer.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> In the projects I am participating in, I always recommend having static
> images
> stored as Smalltalk source code in methods that return a byte array
>
>     html
>         imageWithDocument: (ImageLibrary perform: imageName asSymbol)
>         mimeType: 'image/jpeg'
>         fileName: imageName, '.jpg'.
>
> This produces a large Smalltalk image, but makes versioning and
> configuration
> a lot easier, since the application and the images are guaranteed to be
> in synch.

> ma serverRoot: (FileDirectory default directoryNamed: 'D:\squeak37')
> fullName.
> ma alias: '/seaside' to: [ma addPlug: [:request | seaside process:
> request]].
> ma documentRoot: (FileDirectory default directoryNamed: 'D:\squeak37')
> fullName.
>
> >>BTW: Can I specify other base directories in both cases, or just for
> >>the documentRoot (static content)? Quite a bit confused here...
> >>In other words: Why specify a server root, when it is the same with
> >>FileDirectory default (place of the image)

> Christian Mascher wrote:
>
>  
>> Hello,
>>
>> a question the tutorials didn't help me with: how can I make an
>> image-file show up? I tried this in Counter>>renderContentOn:
>>
>> html image: 'filename.png'
>>    
>
> You'll need to give more of the url since your browser will interpret
> this to be relative to the seaside application's path.  What you want is
> something like:
>
> html image: '/filename.png'.
>
>  
>> [snip]
>>    
>
>  
>> ma serverRoot: (FileDirectory default directoryNamed: 'D:\squeak37')
>> fullName.
>> ma alias: '/seaside' to: [ma addPlug: [:request | seaside process:
>> request]].
>> ma documentRoot: (FileDirectory default directoryNamed: 'D:\squeak37')
>> fullName.
>>
>>    
>>>> BTW: Can I specify other base directories in both cases, or just for
>>>> the documentRoot (static content)? Quite a bit confused here...
>>>> In other words: Why specify a server root, when it is the same with
>>>> FileDirectory default (place of the image)
>>>>        
>
> I don't think there are any Kom modules that actually use the serverRoot
> assignment.  It could probably ???? be removed without any problems.
>
> As for documentRoot:, if you don't do that then ModuleAssembly will not
> add a "ModDoc" to your module stack...in which case files will not be
> served by Kom.  The Kom architecture is pretty straightforward so feel
> free to have a look.  The most instructive thing to do is to build a
> module stack yourself, without using ModuleAssembly.  BTW, despite its
> name ModuleAssembly is not an assembly of modules, it is more of a verb
> "module assembler".  You simple use MA to build your module stack and
> then you discard it.  If you explore "Services serviceNamed: 'http'" you
> can see what the module stack looks like.
>
>  
>> Now I could go to http://localhost:9090/ and the server would give me
>> a static index.html I put in the directory 'D:\squeak37'. But the
>> image referenced in this file could still not be loaded. So no wonder
>> it didn't work in the seaside-application. Still the image-file is
>> there and I can open it with FileList in squeak, so the format seems OK.
>>    
>
>
> There was an incompatibility between older Kom and Squeak 3.8.  It
> effected serving images among other things.  Try updating Kom from
> SqueakMap and see if that helps.  If not please feel free to drop me a
> line off-list.
>  

> Brad Fuller wrote:
>  
>> I don't quite understand why one would have to restart the server to
>> serve a static image file in a directory.
>> Isn't there a default directory from which to place files that can be
>> served? And if so, what is it? I only see Resource Base Url as a setting
>> in config, but I don't know what that is.
>>    
> Yes, you certainly don't have to restart your server just to get it to
> serve files but I don't understand the rest of your question.  Seaside
> doesn't serve files, Kom (or Swazoo) does.  

>  
>> I suppose it is better to create a dictionary of graphics if they are
>> small so that locating the image is not a problem every time.
>> How do others do it? What is the best way to serve graphics (be it small
>> or large!)
>
> Through an apache front end, ultimately.  Serving large files from
> Squeak is a bad idea on production systems...Squeak's file I/O blocks
> the entire VM (not just the Squeak process doing the I/O).  It works
> fine for small apps and images though.  Serving files from Kom is also
> the probably best config for development since it reduces the potential
> sources of problems.
>  

>>The Resource Base URL
>>configuration stuff is Seaside-related and has nothing to do with Kom.
>>  
>>    
>>
>Can you tell me what Resource Base is? Or point me to a place to find
>out more about the /seaside/config page?
>I've read your link to Avi's email in your tutorial.
>  
>

>>
>>
>>  
>>    
>>
>that's what I ended up doing for audio files for people to dnl/listen
>to. But, I gave the complete URL for the anchor. It would be better if
>there was a way to set a path and then use a relative URL, though. Is there?
>  
>

> Jimmie Houchin wrote:
>
>> Hello,
>>
>> Let me see if I understand correctly here.
>>
>> Squeak's file I/O blocks, so any activity which requires file access
>> impacts the performance.
>
> Yes.  Of course the real impact depends a lot on application usage
> patterns (is it the same image file being served many times to the same
> user?  a bunch of different users?  a bunch a different image files?).
> It also depends on how well browser caching is working or if you're
> using a front-end cache (like squid) how well it is working.

> David Shaffer wrote:
> > Jimmie Houchin wrote:
> >
> >> Hello,
> >>
> >> Let me see if I understand correctly here.
> >>
> >> Squeak's file I/O blocks, so any activity which requires file access
> >> impacts the performance.
> >
> > Yes.  Of course the real impact depends a lot on application usage
> > patterns (is it the same image file being served many times to the same
> > user?  a bunch of different users?  a bunch a different image files?).
> > It also depends on how well browser caching is working or if you're
> > using a front-end cache (like squid) how well it is working.
>
> Yes, I understand that the application makes a tremendous difference.
> Myself, I prefer to let Apache, Lighttpd, etc. server truly static
> content. So I guess I was fishing for confirmation that local use of the
> filesystem has its costs.
>
> I guess this would also be born in use of Magma for DB.
>
> I guess the more in memory inside the image the better.
>
> >> What about the network I/O? Is it non-blocking?
> >
> > Yes, network I/O is non-blocking (the Squeak UNIX VM has a polling-based
> > custom asynchronous I/O model).
>
> Bueno.