static image files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

static image files

Christian Mascher
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'

but nothing happened. First I thought it was the directory-problem. If I
put the image in the same directory as the squeak .image and .exe is an
URI with just the filename correct in this case?

Then I found in another tutorial, I have to tell WAKom to serve static
files as well. So I did this (from the Schaffer-tutorial, with the
FileRoot renamed):

"Kill all existing Kom HTTP servers"
HttpService allInstancesDo: [:each | each stop. each unregister].
"Start a new server on port 9090 servering both static content and
seaside apps"
| ma seaside |
seaside := WAKomEncoded default.
ma := ModuleAssembly core.
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)

ma directoryIndex: 'index.html index.htm'.
ma serveFiles.
(HttpService startOn: 9090 named: 'httpd') plug: ma rootModule

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.

Whats going on?

Thanks

Christian


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Göran Krampe
Hi Christian!

I actually added very simple support for this in Seaside2.6a3-gk.6.mcz
(you find it on www.squeaksource.com/Seaside) which Avi then merged into
2.6a3 in a subsequent version.

regards, Göran
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Michel Bany-3
In reply to this post by Christian Mascher
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.

On how to store static images into Smalltalk methods in VW, load parcel
named
"SeasideWebDesignerTool" and located in the BonusPack folder.
See a demo at http://mbany.ath.cx/seaside/go/WebDesignerTool

Michel.

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Lukas Renggli
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
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Philippe Marschall
+10

2006/2/8, Lukas Renggli <[hidden email]>:

> 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
>
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Esteban A. Maringolo
In reply to this post by Michel Bany-3
2006/2/8, Michel Bany <[hidden email]>:

> 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.

This is true, but "how much large" images are we talking about?
If it's about small pictures such as icons, buttons, and similar ones
is acceptable, but if you have a photogallery, or many many pictures
is questionable.

In the case of Commanche I can't tell, but in the case of Swazoo based
implementations, other alternative (_additionaly_ to the one you
mention) is to have a FileResource, and a couple of methods in html
builder to reference such files.

Best regards,

--
Esteban A. Maringolo
[hidden email]
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

cdavidshaffer
In reply to this post by Christian Mascher
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.

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Christian Mascher
David Shaffer wrote:

> 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.

That was it!!! Thanks. I can see the image in an index.html now just as
expected. (I spent hours yesterday, trying to get it running. So I
actually did understand it right.)

Christian

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Christian Mascher
[ The images Kom didn't serve static images, update fixed that. ]

BTW: I used the standard image as downloaded from the seaside website
(about 6 weeks ago.) This could bite more Newbies than just me ...

Christian

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Avi  Bryant
In reply to this post by Lukas Renggli

On Feb 8, 2006, at 3:34 AM, Lukas Renggli wrote:

> 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.

I think it's a good idea, but I don't personally have my head around  
how this would work.  It would probably be easier to discuss if there  
were some proof of concept implementation to play with...

Avi
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Brad Fuller
In reply to this post by cdavidshaffer
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.

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!)

thanks,

brad

(BTW: I've spent several days creating a seaside website from scratch
and I'm almost ready to deploy a _BASIC_ version of it. Still got some
kinks. I'm having quite a bit of fun. Seaside is wonderful. I hope that
we can do more than we could with Flash. Certainly looks so.)


David Shaffer wrote:

> 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.
>  

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

cdavidshaffer
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.  The Resource Base URL
configuration stuff is Seaside-related and has nothing to do with Kom.
If you have a Kom server up and running you can simply add the
appropriate modules to it to configure it to serve files.  I think you
will find this complicated at first but doable.  My Squelenium project
has an installation script which scans a Kom stack and inserts new
modules into it as needed (it is on SqueakMap).  It might make a good
example for you.  The script I provide in my tutorial (which grew out of
one I copied from a Wiki) tries to start from a blank slate to avoid
problems associated with dealing with other people's configurations.

>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.

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Brad Fuller
Thanks much for the reply, David.

some comments/questions:

David Shaffer wrote:

> 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.  
Right... I understand... but, I admit I need to keep that separate in my
mind.
> 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.
> If you have a Kom server up and running you can simply add the
> appropriate modules to it to configure it to serve files.  I think you
> will find this complicated at first but doable.  My Squelenium project
> has an installation script which scans a Kom stack and inserts new
> modules into it as needed (it is on SqueakMap).  It might make a good
> example for you.  The script I provide in my tutorial (which grew out of
> one I copied from a Wiki) tries to start from a blank slate to avoid
> problems associated with dealing with other people's configurations.
>  
BTW, your tutorial is very helpful. Thanks! I'm looking forward to the
other areas when finished!
I'll check out Squelenium.

>  
>> 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.
>  
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?

thanks again for taking the time to reply!

brad

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

cdavidshaffer
Brad Fuller wrote:

>>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.
>  
>
It was added in 2.6 so I don't know much about it.  A quick browse
through the various senders etc makes me think that it works as you
expect.  You set it on the configuration page then when you want to
specify an image (for example) relative to this base you simply send
"resourceUrl: someRelativePath" and the canvas code will generate an
absolute URL.  Look for senders of absoluteUrlForResource: to see a list
of tags which seem to use this feature.  Notice that the scripts and
styles paths seemed tied to this as well.  I think this follows pretty
standard usage pattern.  I would set the resource base to
"http://localhost:9090/myFiles" then inside the directory served by
myFiles place directories for your scripts, styles and images.  Then you
could:

html image
    resourceUrl: 'images/whatever'

The alternative is to roll your own configuration stuff.  If you want to
see how that would work look at my tutorial on configurations (which
will not work in 2.6 w/o a couple small changes) then for a specific
example look at WARenderLoopConfiguration>>attributes to see how
#baseResourceUrl was defined.

 

>BTW, your tutorial is very helpful. Thanks! I'm looking forward to the
>other areas when finished!
>I'll check out Squelenium.
>  
>

Thanks Brad.  I wish I could work on it more...it really needs a lot of
work (like moving to Canvas, finishing incomplete sections etc).  I do
have new material but there are some large problems with it...should be
ironed out in the next month or so though.

>>
>>
>>  
>>    
>>
>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?
>  
>
(See above.)  You could, of course, change the baseResourceUrl to point
to your apache-served content in the deployed environment.  This is
exactly what I do (although I don't use 2.6 so I have my own
configuration parameters).

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Göran Krampe
In reply to this post by Brad Fuller
Hi!

Brad Fuller <[hidden email]> wrote:
> How do others do it? What is the best way to serve graphics (be it small
> or large!)

Well, for small image files I added WACachedDocument and code, which Avi
merged into Seaside2.6-a3, here is the class comment:
------------------
This class is for serving smallish files like PNG images etc using
WADocumentHandler. Using the Canvas API for HTML generation you simply
do this:

        html image fileName: 'myimage.png'

or:

        html image fileName: 'myimage.blurp' mimeType: 'blurp'

This will create a request handler in your WAApplication registry that
is accessible on a unique URL and does not expire.
The actual contents of the file will only be read upon first access, we
could augment this class with smarter caching, like checking the
modification time on disk.

The class has a Cache class var holding a Dictionary of created
instances so you can clear and preload files into the image using:

        WACachedDocument
                clearCache;
                fileName: 'myimage.png';
                fileName: 'another.gif'; "etc"
                preloadCache
-------------

Of course, this code could be further hacked to also deal with large
files (without reading them in full into the image) but you would need
to hack into WAResponse etc.

regards, Göran
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Jimmie Houchin
In reply to this post by cdavidshaffer
David Shaffer wrote:
[snip]
>
> 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.

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.

What about the network I/O? Is it non-blocking?

Are there any significant problems when a request requires some
time-consuming action before returning? Such as calling other servers
web services. Does it negatively impact other requests?

Thanks for any wisdom or insight.

Jimmie

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Re: static image files

cdavidshaffer
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.

>
> 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).

>
> Are there any significant problems when a request requires some
> time-consuming action before returning? Such as calling other servers
> web services. Does it negatively impact other requests?

If the operation is in squeak and is CPU intensive fork it off at a
lower priority and have the request thread wait on a semaphore for the
compute intensive process to complete.  Calling web services would take
advantage of the non-blocking socket I/O calls.

>
>
> Thanks for any wisdom or insight.

:-) I hope that it turns out to be helpful. :-)

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Jimmie Houchin-2
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.

>> Are there any significant problems when a request requires some
>> time-consuming action before returning? Such as calling other servers
>> web services. Does it negatively impact other requests?
>
> If the operation is in squeak and is CPU intensive fork it off at a
> lower priority and have the request thread wait on a semaphore for the
> compute intensive process to complete.  Calling web services would take
> advantage of the non-blocking socket I/O calls.

Great

>> Thanks for any wisdom or insight.
>
> :-) I hope that it turns out to be helpful. :-)

Most definitely. Thanks.

Jimmie

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Re: static image files

David T. Lewis
On Tue, Feb 28, 2006 at 12:02:51AM +0000, Jimmie Houchin wrote:

> 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.

This actually works equally well for file I/O, since the aio functions
in the Unix VM work for any socket or file descriptor. AioPlugin on
Squeak Map will show you how it works. There is also an AsyncFile
class in Squeak that presumably does similar things.

Dave

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: static image files

Jimmie Houchin-2
David T. Lewis wrote:
> On Tue, Feb 28, 2006 at 12:02:51AM +0000, Jimmie Houchin wrote:
[snip]
>>>> 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.
>
> This actually works equally well for file I/O, since the aio functions
> in the Unix VM work for any socket or file descriptor. AioPlugin on
> Squeak Map will show you how it works. There is also an AsyncFile
> class in Squeak that presumably does similar things.


Great!

I'm currently working on learning how to compile Squeak on my computer.
I want OSProcess. I desperately want to be able to quit using Python for
some of the scripting I'm doing. But I got to be able to call
cdparanoia, lame, etc.

My problem so far has been learning how to compile 32bit Squeak on my
64bit Ubuntu.

I'll probably cheat on do a 32bit install on a machine for such times.

I'll definitely look into the AioPlugin and the AsyncFile.

Thanks for the info.

Jimmie

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
12