saving an image while serving

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

Re: saving an image while serving

Bob Arning
That might be a bit strong. Depending on the nature of the in-image data, it might not be too hard to export the data in some neutral format which could be imported into a newer version image. YMMV.

Cheers,
Bob

On 4/18/11 8:00 AM, Philippe Marschall wrote:
you'll also
never be able to switch to a new version of your dialect

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

Re: saving an image while serving

Philippe Marschall
2011/4/18 Bob Arning <[hidden email]>:
> That might be a bit strong. Depending on the nature of the in-image data, it
> might not be too hard to export the data in some neutral format which could
> be imported into a newer version image. YMMV.

It's not possible for SqueakSource, not without serious effort. The
last time it was done "interesting" issues popped up like the object
format of Timestamp changed. And supposedly fast import/export
mechanism like SmartRefStream become unusably slow.

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

Re: saving an image while serving

sebastianconcept@gmail.co
In reply to this post by Philippe Marschall
ok, then our dear squeaksource is an anti-example on that too





On Apr 18, 2011, at 9:00 AM, Philippe Marschall wrote:

> 2011/4/18 Janko Mivšek <[hidden email]>:
>> Hi guys,
>>
>> Let me support Nevin claims strongly with my the same experiences with
>> image based persistency. Anyone just enough pragmatic and with a bit of
>> probability calculus can soon discover, how right Nevin is.
>>
>> I know that from my experience, ok, with VisualWorks images, which
>> snapshot every hour. One such sole image hosts 50+ sites and in last 8
>> years without any loss of data. We have just few crashes (around 2-4 per
>> year) because of DOS attacks, and that's all.
>>
>> It is true that there is 1 hour window to loose data and that we had
>> luck loosing nothing during those few (mostly nightly) crashes, but when
>> I compare that with horror stories of friends using, say MySql...
>>
>> Of course such image is backup every hour, every night - just plain
>> usual safety measures therefore.
>
> Everyone how thinks image based persistence is a good idea please look
> at SqueakSource. Not only do you suffer from the impacts of the
> non-transactional behavior (yes, data got lost several times in the
> past, the image hangs for quite some time when saving) you'll also
> never be able to switch to a new version of your dialect and you are
> limited to one image doing the processing.
>
> Cheers
> Philippe
> _______________________________________________
> 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: saving an image while serving

drush66
In reply to this post by Philippe Marschall
On Mon, Apr 18, 2011 at 3:42 PM, Philippe Marschall
<[hidden email]> wrote:
> It's not possible for SqueakSource, not without serious effort. The
> last time it was done "interesting" issues popped up like the object
> format of Timestamp changed. And supposedly fast import/export
> mechanism like SmartRefStream become unusably slow.

I must say that I am also one who is very uneasy when my data is
stored in the image, including my pier based blog. If procedures to
export and import data are not seriously tested, they tend to become
slightly unworkable when situation arises. If they are thoroughly
tested and maintained, why bother with image based persistence?

Btw, there was a quite large data availability incident with DabbleDB
that lasted for weeks and affected many clients, does any one know
details of what caused it?

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

Re: saving an image while serving

sebastianconcept@gmail.co
In reply to this post by NorbertHartl
"But you cannot scale horizontally just simply"

Not working the way Nevin does. But that's not the Nevin's case. He's saying this "yes is one image, yes if it crashes we need to rollback, yes that architecture doesn't scale horizontally so what? is enough for the business it get us there just fine." (Nevin please correct me if I'm wrong)

Our case is different. Image persistence didn't fit our needs. We really needed to be able to scale horizontally. The way we found is to treat images like servers. Any user is be able to be attended by any image. That's how you do it.

Sticky sessions is a non issue once the httpd is configured (and properly balanced). About being forced to use a central data storage, that sounds plain wrong. I mean at design level. To be able to scale horizontally any time you have to design in a way that doesn't generate points of contention. How you design evading points of contention is an art. You need to find your most convenient way for your application. In our case we used one object database per group of people. Lots of groups, plenty of room for everybody's activity.

About memory size in images, we monitor the images and restart them as needed. The worst thing that can happen in an image restart is that you see your last request failed and in your next request, the http balancer sends you to another image. This is ACID so things gets done or do not. Nothing is lost.

That could happen with any image in any server (hardware).

About oversimplification and *most* scenarios: I'm sharing with you guys some details on how we got this thing done. What I'm not doing is trying to make people decide on "this" or "that" like some people suggested. Who the f* will invest or employ a guy deciding architecture like that? I'm making my case because is working and I think some could find it interesting or useful.

I thought it was clear but... hey, I'm counting with the intelligence and critical thinking of the reader. Always. 

Seriously, who decides the architecture of a startup in what he/she reads on a f* list?

Do your homework. If it f* works, then it does. If it doesn't, then it doesn't. 

with love




On Apr 18, 2011, at 3:19 AM, Norbert Hartl wrote:


Am 17.04.2011 um 20:13 schrieb Sebastian Sastre:

The only realistic way we see for that is by scaling horizontally.

Many many worker images will do. And if people needs more, well... you simply add more.

I would really like to discuss this with Nevin and you. Most of the time you cannot "...simply add more" images. I would like to know what setups you have. In a web scenario where data is created by web clients in the image you can have it in one image, right. But you cannot scale horizontally just simply. You need to take special action like sticky sessions/domain partitioning if the domain model is not highly inter-connected or you forced to use a central data storage.
If you can solve it this way than you are lucky guys. Btw. is there a memory size in pharo from which performance will degrade faster?

I agree with you guys that you can achieve a lot with a simple image. But it sounded to me like an over-simplification of deployments which won't work in many scenarios.

Norbert

Of course that caution should be taken in the income/spending on validable* equations (monetization, customer adquisition, workers per server costs, etc) so things can grow smoothly.

*by validable equations I mean the math that comes out from the experience (and not math based on assumptions)



On Apr 17, 2011, at 6:29 AM, Norbert Hartl wrote:


Am 17.04.2011 um 01:57 schrieb Igor Stasenko:

This is really good to hear that.

I leaned something new. Usual way of design is to prevent failure(s).
But going that way we tend to forget that failures are inevitable, and
paying little attention towards what can be done
to restart/reload data from backups quickly and easily.
Indeed, embracing failure is the way we should design our systems.

Well, I can tell if you plan big systems than the failure scenarios planning takes a big part of the overall planning. There you embrace failures very very much. You can't go anywhere with something that is not redundant in at least one dimension. And the software has to fit in the hardware planning. So, not embracing failure is a pleasure that only hobbyists and smaller companies can have.

Norbert

On 17 April 2011 01:37, Nevin Pratt <[hidden email]> wrote:
Define "handful".  You'd be surprised.

We are a large enough company with enough orders, to support more than a
dozen employees, and a half a dozen contractors.  Our warehouse/office is
now about 26,000 square feet.  And, we're growing, and profitable, with 2011
looking to be our best year ever.

The exact numbers are confidential, but I am confident that we are the
largest company on the planet in our field (i.e., "Reborn Doll Supplies").

Besides, the orders aren't exactly "hand reentered".  I just didn't give
enough detail, because I didn't feel it was relevant.  We have an admin page
that can easily slurp the data in rapidly, if needed.  It's not hard to do.

And Squeak/Seaside has served us well.  And we just use the image for
persistence, as previously mentioned.  And we are very happy with it.

Nevin


Of course that only works when you have a handful of orders to reenter,
which isn't the case for most systems.

Sent from my iPhone
On 2011-04-16, at 12:41, "Sebastian Sastre" <[hidden email]>
wrote:

So, 15 minutes times 4 makes a whole hour per year.
Beautiful :)
Doesn't even justify to implement automation of the manual rollback (that
sounds feasible)



On Apr 16, 2011, at 1:29 PM, Nevin Pratt wrote:

Sebastion, that is *exactly* what I initially did at Bountiful Baby.
However, it has been several *years* since I've had to do your #4, so things
have changed slightly since.

Bountiful Baby is an eCommerce site, and the critical "object graph" (your
#2, below) information consists of inventory data (the website keeps track
of our inventory), and gift certificate data (for gift certificates that
have been issued).  Also, whenever either of those datums change, the
website sends an email-- for example, emails are (obviously) sent for each
order accepted, and, it sends emails when it issues a gift certificate.  So,
it is easy to discover (via the emails) what data was lost since the last
image crash.

Consequently, currently this is what happens:

1. image is saved from time to time (usually daily), and copied to a
separate "backup" machine.
2. if anything bad happens, the last image is grabbed, and the orders and/or
gift certificates that were issued since the last image save are simply
re-entered.

And, #2 has been *very* rarely done-- maybe a two or three times a year, and
then it turns out it is usually because I did something stupid.

For us, it's a whole lot easier to do persistence this way than bothering
with any persistence mechanism.  And, it turns out, it is *very* reliable,
with exactly one easily fixable glitch:

The glitch is: occasionally the production image UI will freeze, for no
known reason.  It doesn't effect Seaside, though, so the website keeps going
just fine.  And, if we run the "screenshot" app (in the configuration
screen), there is a link at the top for "Suspend UI Process", and "Resume UI
Process".  Just suspend and resume, and the UI becomes unstuck.

We've been doing persistence this way for years now, and I've been
*extremely* impressed with the reliability.

Before that, we used PostgreSQL and GLORP for persistence.  But I yanked
that code out years ago.  It wasn't worth the bother maintaining it.

If you have a daily image save, then on average there will be 12 hours of
lost data on a "random" crash.  Re-entering 12 hours of orders and/or gift
certificates (discovered from the emails, as mentioned above) might take 10
to 15 minutes.  Not a big deal at all for us.

Ten years ago I wouldn't have even considered doing persistence this way,
but I've changed.  Squeak has changed.  Seaside has changed.  And all for
the better.

Nevin



Given that you don't need transactions, to make that style work, I suggest
this:
1. save the image from time to time (as best suits your needs) like you're
doing now
2. use a secondary way to dump the object graph
3. use the normal image for as long as things are good
4. when shit happens you "transplant" the object graph into a new
"reincarnation" of your app in a fresh image
5. repeat
For dumping the ODB you have options: image segments, SIXX comes to mind now
If you make for yourself some "rescue" kit (script, tools, preloaded code in
fresh image), you can make 4 quite painless (or, why not, monitored and
automated)
sebastian
o/


On Apr 16, 2011, at 12:23 PM, Michal wrote:

hi -

Despite the warnings, I am really interested in sticking to the
simplest way of saving my seaside application data, ie periodically
saving and backuping the image. The seaside book states that

"saving [the image] while processing http requests is a risk you
want to avoid."

What is the status on that? Is that something we can fix? I have been
running an image in this mode for a few weeks, with no ill effect so
far, but I have had major problems with old image/vm combinations. So
is this something that might be fixed already?

Also, I recall that Avi had made a number of attempts at having an
image saved in a forked background process, eg

http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-October/095547.html

did anybody pick up on this, or did anything come out of it?

thanks,
Michal
_______________________________________________
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

_______________________________________________
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

_______________________________________________
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





--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
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

_______________________________________________
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


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

Re: saving an image while serving

NorbertHartl
Sebastian,

I personally was just fishing for deployment scenarios because I think it is important and could be added in some documentation. And that's why I was inquiring into depth. I think it is very valuable to know that you can just use image persistence if you meet the following criteria: Your model fits completely in the memory and concurrency is not that high. Or your model can be separated into distinct parts that you can spread over multiple images. Or you create some logging of the transcractions that you can pull back in if you experience a crash. Or you can rollback without much problems and that is feasible because crashes do not occurr that often.

I just didn't get Nevins approach. On the one hand he has everything in his image on the other hand he can "pull back in data" after experiencing a crash. That doesn't fit in my head. Nothing more I wanted to know.

Your statement that you can just simply scale is not proper without declaring the assumptions. And I would just want to hear your approach so it is documented as well and might enlight a lot of people like stubborn me.

Am 18.04.2011 um 15:59 schrieb Sebastian Sastre:

"But you cannot scale horizontally just simply"

Not working the way Nevin does. But that's not the Nevin's case. He's saying this "yes is one image, yes if it crashes we need to rollback, yes that architecture doesn't scale horizontally so what? is enough for the business it get us there just fine." (Nevin please correct me if I'm wrong)

It is not judging about architectural decisions. If it works it is fine. Who wants to argue?

Our case is different. Image persistence didn't fit our needs. We really needed to be able to scale horizontally. The way we found is to treat images like servers. Any user is be able to be attended by any image. That's how you do it.

Sticky sessions is a non issue once the httpd is configured (and properly balanced). About being forced to use a central data storage, that sounds plain wrong. I mean at design level. To be able to scale horizontally any time you have to design in a way that doesn't generate points of contention. How you design evading points of contention is an art. You need to find your most convenient way for your application. In our case we used one object database per group of people. Lots of groups, plenty of room for everybody's activity.

That's what I meant by saying domain partitioning. To me it doesn't matter if it is partioned in domains or access layers. If you think towards social networks your contention point free design might be hard to work out. 

About memory size in images, we monitor the images and restart them as needed. The worst thing that can happen in an image restart is that you see your last request failed and in your next request, the http balancer sends you to another image. This is ACID so things gets done or do not. Nothing is lost.

Well, that must be another approach than the "object database per group of people". 

That could happen with any image in any server (hardware).

About oversimplification and *most* scenarios: I'm sharing with you guys some details on how we got this thing done. What I'm not doing is trying to make people decide on "this" or "that" like some people suggested. Who the f* will invest or employ a guy deciding architecture like that? I'm making my case because is working and I think some could find it interesting or useful.

Again, I just asked because what you said wasn't clear to me. This confirms I'm someone that "find it interesting or useful". But in order to let me understand it you might need to answer some questions. If this is not what you want I can take it that way.

I thought it was clear but... hey, I'm counting with the intelligence and critical thinking of the reader. Always. 

You are right and the outcome of that is often a question.

Seriously, who decides the architecture of a startup in what he/she reads on a f* list?

I don't know. But I could imagine there are some people reading this list that are interested in exactly how you did it as an example of how things can be done. Most people will have a n-tier architecture as a background. It is hard to believe for them that you don't need it. And here you go and explain it. Than they have to decide if you are a genius or a jerk. That's up to them.

Do your homework. If it f* works, then it does. If it doesn't, then it doesn't. 

Agreed.

piece,

Norbert



On Apr 18, 2011, at 3:19 AM, Norbert Hartl wrote:


Am 17.04.2011 um 20:13 schrieb Sebastian Sastre:

The only realistic way we see for that is by scaling horizontally.

Many many worker images will do. And if people needs more, well... you simply add more.

I would really like to discuss this with Nevin and you. Most of the time you cannot "...simply add more" images. I would like to know what setups you have. In a web scenario where data is created by web clients in the image you can have it in one image, right. But you cannot scale horizontally just simply. You need to take special action like sticky sessions/domain partitioning if the domain model is not highly inter-connected or you forced to use a central data storage.
If you can solve it this way than you are lucky guys. Btw. is there a memory size in pharo from which performance will degrade faster?

I agree with you guys that you can achieve a lot with a simple image. But it sounded to me like an over-simplification of deployments which won't work in many scenarios.

Norbert

Of course that caution should be taken in the income/spending on validable* equations (monetization, customer adquisition, workers per server costs, etc) so things can grow smoothly.

*by validable equations I mean the math that comes out from the experience (and not math based on assumptions)



On Apr 17, 2011, at 6:29 AM, Norbert Hartl wrote:


Am 17.04.2011 um 01:57 schrieb Igor Stasenko:

This is really good to hear that.

I leaned something new. Usual way of design is to prevent failure(s).
But going that way we tend to forget that failures are inevitable, and
paying little attention towards what can be done
to restart/reload data from backups quickly and easily.
Indeed, embracing failure is the way we should design our systems.

Well, I can tell if you plan big systems than the failure scenarios planning takes a big part of the overall planning. There you embrace failures very very much. You can't go anywhere with something that is not redundant in at least one dimension. And the software has to fit in the hardware planning. So, not embracing failure is a pleasure that only hobbyists and smaller companies can have.

Norbert

On 17 April 2011 01:37, Nevin Pratt <[hidden email]> wrote:
Define "handful".  You'd be surprised.

We are a large enough company with enough orders, to support more than a
dozen employees, and a half a dozen contractors.  Our warehouse/office is
now about 26,000 square feet.  And, we're growing, and profitable, with 2011
looking to be our best year ever.

The exact numbers are confidential, but I am confident that we are the
largest company on the planet in our field (i.e., "Reborn Doll Supplies").

Besides, the orders aren't exactly "hand reentered".  I just didn't give
enough detail, because I didn't feel it was relevant.  We have an admin page
that can easily slurp the data in rapidly, if needed.  It's not hard to do.

And Squeak/Seaside has served us well.  And we just use the image for
persistence, as previously mentioned.  And we are very happy with it.

Nevin


Of course that only works when you have a handful of orders to reenter,
which isn't the case for most systems.

Sent from my iPhone
On 2011-04-16, at 12:41, "Sebastian Sastre" <[hidden email]>
wrote:

So, 15 minutes times 4 makes a whole hour per year.
Beautiful :)
Doesn't even justify to implement automation of the manual rollback (that
sounds feasible)



On Apr 16, 2011, at 1:29 PM, Nevin Pratt wrote:

Sebastion, that is *exactly* what I initially did at Bountiful Baby.
However, it has been several *years* since I've had to do your #4, so things
have changed slightly since.

Bountiful Baby is an eCommerce site, and the critical "object graph" (your
#2, below) information consists of inventory data (the website keeps track
of our inventory), and gift certificate data (for gift certificates that
have been issued).  Also, whenever either of those datums change, the
website sends an email-- for example, emails are (obviously) sent for each
order accepted, and, it sends emails when it issues a gift certificate.  So,
it is easy to discover (via the emails) what data was lost since the last
image crash.

Consequently, currently this is what happens:

1. image is saved from time to time (usually daily), and copied to a
separate "backup" machine.
2. if anything bad happens, the last image is grabbed, and the orders and/or
gift certificates that were issued since the last image save are simply
re-entered.

And, #2 has been *very* rarely done-- maybe a two or three times a year, and
then it turns out it is usually because I did something stupid.

For us, it's a whole lot easier to do persistence this way than bothering
with any persistence mechanism.  And, it turns out, it is *very* reliable,
with exactly one easily fixable glitch:

The glitch is: occasionally the production image UI will freeze, for no
known reason.  It doesn't effect Seaside, though, so the website keeps going
just fine.  And, if we run the "screenshot" app (in the configuration
screen), there is a link at the top for "Suspend UI Process", and "Resume UI
Process".  Just suspend and resume, and the UI becomes unstuck.

We've been doing persistence this way for years now, and I've been
*extremely* impressed with the reliability.

Before that, we used PostgreSQL and GLORP for persistence.  But I yanked
that code out years ago.  It wasn't worth the bother maintaining it.

If you have a daily image save, then on average there will be 12 hours of
lost data on a "random" crash.  Re-entering 12 hours of orders and/or gift
certificates (discovered from the emails, as mentioned above) might take 10
to 15 minutes.  Not a big deal at all for us.

Ten years ago I wouldn't have even considered doing persistence this way,
but I've changed.  Squeak has changed.  Seaside has changed.  And all for
the better.

Nevin



Given that you don't need transactions, to make that style work, I suggest
this:
1. save the image from time to time (as best suits your needs) like you're
doing now
2. use a secondary way to dump the object graph
3. use the normal image for as long as things are good
4. when shit happens you "transplant" the object graph into a new
"reincarnation" of your app in a fresh image
5. repeat
For dumping the ODB you have options: image segments, SIXX comes to mind now
If you make for yourself some "rescue" kit (script, tools, preloaded code in
fresh image), you can make 4 quite painless (or, why not, monitored and
automated)
sebastian
o/


On Apr 16, 2011, at 12:23 PM, Michal wrote:

hi -

Despite the warnings, I am really interested in sticking to the
simplest way of saving my seaside application data, ie periodically
saving and backuping the image. The seaside book states that

"saving [the image] while processing http requests is a risk you
want to avoid."

What is the status on that? Is that something we can fix? I have been
running an image in this mode for a few weeks, with no ill effect so
far, but I have had major problems with old image/vm combinations. So
is this something that might be fixed already?

Also, I recall that Avi had made a number of attempts at having an
image saved in a forked background process, eg

http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-October/095547.html

did anybody pick up on this, or did anything come out of it?

thanks,
Michal
_______________________________________________
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

_______________________________________________
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

_______________________________________________
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





--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
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

_______________________________________________
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

_______________________________________________
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: saving an image while serving

sebastianconcept@gmail.co
On Apr 18, 2011, at 11:36 AM, Norbert Hartl wrote:

Sebastian,

I personally was just fishing for deployment scenarios because I think it is important and could be added in some documentation. And that's why I was inquiring into depth. I think it is very valuable to know that you can just use image persistence if you meet the following criteria: Your model fits completely in the memory and concurrency is not that high. Or your model can be separated into distinct parts that you can spread over multiple images. Or you create some logging of the transcractions that you can pull back in if you experience a crash. Or you can rollback without much problems and that is feasible because crashes do not occurr that often.

The documentation is the right place to clarify those ideas. The reader will know if it fits or not. I would add a disclaimer saying that things can go wrong and a secondary way to dump and import the object graph is emphatically suggested.


I just didn't get Nevins approach. On the one hand he has everything in his image on the other hand he can "pull back in data" after experiencing a crash. That doesn't fit in my head. Nothing more I wanted to know.

I don't know how Nevin does the "pull back in data" but if you wan't an idea to start visualizing that happening think a SIXX dump being read in a fresh image. There is even a guy that worked on a way to do that streaming the XML to dump big data.

Another idea is ReferenceStream.


Your statement that you can just simply scale is not proper without declaring the assumptions. And I would just want to hear your approach so it is documented as well and might enlight a lot of people like stubborn me.

Sure, that's why I've answered the email, to clarify our assumptions.

...
That's what I meant by saying domain partitioning. To me it doesn't matter if it is partioned in domains or access layers. If you think towards social networks your contention point free design might be hard to work out. 

for social it makes sense to make an odb per guy. The golden dream would be not partition at all but I don't see that feasible. We find out that in our domain one odb per group was a good design trade off.

...
Well, that must be another approach than the "object database per group of people". 

I didn't get what you mean, that's exactly how it's working for us today. You open an account for your company (group of people) and when you activate it it creates an odb for you. That's it.

...Most people will have a n-tier architecture as a background. It is hard to believe for them that you don't need it. And here you go and explain it. Than they have to decide if you are a genius or a jerk. That's up to them.

Yes. That's totally fine. And fair. And intriguing :)



Am 18.04.2011 um 15:59 schrieb Sebastian Sastre:

"But you cannot scale horizontally just simply"

Not working the way Nevin does. But that's not the Nevin's case. He's saying this "yes is one image, yes if it crashes we need to rollback, yes that architecture doesn't scale horizontally so what? is enough for the business it get us there just fine." (Nevin please correct me if I'm wrong)

It is not judging about architectural decisions. If it works it is fine. Who wants to argue?

Our case is different. Image persistence didn't fit our needs. We really needed to be able to scale horizontally. The way we found is to treat images like servers. Any user is be able to be attended by any image. That's how you do it.

Sticky sessions is a non issue once the httpd is configured (and properly balanced). About being forced to use a central data storage, that sounds plain wrong. I mean at design level. To be able to scale horizontally any time you have to design in a way that doesn't generate points of contention. How you design evading points of contention is an art. You need to find your most convenient way for your application. In our case we used one object database per group of people. Lots of groups, plenty of room for everybody's activity.

That's what I meant by saying domain partitioning. To me it doesn't matter if it is partioned in domains or access layers. If you think towards social networks your contention point free design might be hard to work out. 

About memory size in images, we monitor the images and restart them as needed. The worst thing that can happen in an image restart is that you see your last request failed and in your next request, the http balancer sends you to another image. This is ACID so things gets done or do not. Nothing is lost.

Well, that must be another approach than the "object database per group of people". 

That could happen with any image in any server (hardware).

About oversimplification and *most* scenarios: I'm sharing with you guys some details on how we got this thing done. What I'm not doing is trying to make people decide on "this" or "that" like some people suggested. Who the f* will invest or employ a guy deciding architecture like that? I'm making my case because is working and I think some could find it interesting or useful.

Again, I just asked because what you said wasn't clear to me. This confirms I'm someone that "find it interesting or useful". But in order to let me understand it you might need to answer some questions. If this is not what you want I can take it that way.

I thought it was clear but... hey, I'm counting with the intelligence and critical thinking of the reader. Always. 

You are right and the outcome of that is often a question.

Seriously, who decides the architecture of a startup in what he/she reads on a f* list?

I don't know. But I could imagine there are some people reading this list that are interested in exactly how you did it as an example of how things can be done. Most people will have a n-tier architecture as a background. It is hard to believe for them that you don't need it. And here you go and explain it. Than they have to decide if you are a genius or a jerk. That's up to them.

Do your homework. If it f* works, then it does. If it doesn't, then it doesn't. 

Agreed.

piece,

Norbert



On Apr 18, 2011, at 3:19 AM, Norbert Hartl wrote:


Am 17.04.2011 um 20:13 schrieb Sebastian Sastre:

The only realistic way we see for that is by scaling horizontally.

Many many worker images will do. And if people needs more, well... you simply add more.

I would really like to discuss this with Nevin and you. Most of the time you cannot "...simply add more" images. I would like to know what setups you have. In a web scenario where data is created by web clients in the image you can have it in one image, right. But you cannot scale horizontally just simply. You need to take special action like sticky sessions/domain partitioning if the domain model is not highly inter-connected or you forced to use a central data storage.
If you can solve it this way than you are lucky guys. Btw. is there a memory size in pharo from which performance will degrade faster?

I agree with you guys that you can achieve a lot with a simple image. But it sounded to me like an over-simplification of deployments which won't work in many scenarios.

Norbert

Of course that caution should be taken in the income/spending on validable* equations (monetization, customer adquisition, workers per server costs, etc) so things can grow smoothly.

*by validable equations I mean the math that comes out from the experience (and not math based on assumptions)



On Apr 17, 2011, at 6:29 AM, Norbert Hartl wrote:


Am 17.04.2011 um 01:57 schrieb Igor Stasenko:

This is really good to hear that.

I leaned something new. Usual way of design is to prevent failure(s).
But going that way we tend to forget that failures are inevitable, and
paying little attention towards what can be done
to restart/reload data from backups quickly and easily.
Indeed, embracing failure is the way we should design our systems.

Well, I can tell if you plan big systems than the failure scenarios planning takes a big part of the overall planning. There you embrace failures very very much. You can't go anywhere with something that is not redundant in at least one dimension. And the software has to fit in the hardware planning. So, not embracing failure is a pleasure that only hobbyists and smaller companies can have.

Norbert

On 17 April 2011 01:37, Nevin Pratt <[hidden email]> wrote:
Define "handful".  You'd be surprised.

We are a large enough company with enough orders, to support more than a
dozen employees, and a half a dozen contractors.  Our warehouse/office is
now about 26,000 square feet.  And, we're growing, and profitable, with 2011
looking to be our best year ever.

The exact numbers are confidential, but I am confident that we are the
largest company on the planet in our field (i.e., "Reborn Doll Supplies").

Besides, the orders aren't exactly "hand reentered".  I just didn't give
enough detail, because I didn't feel it was relevant.  We have an admin page
that can easily slurp the data in rapidly, if needed.  It's not hard to do.

And Squeak/Seaside has served us well.  And we just use the image for
persistence, as previously mentioned.  And we are very happy with it.

Nevin


Of course that only works when you have a handful of orders to reenter,
which isn't the case for most systems.

Sent from my iPhone
On 2011-04-16, at 12:41, "Sebastian Sastre" <[hidden email]>
wrote:

So, 15 minutes times 4 makes a whole hour per year.
Beautiful :)
Doesn't even justify to implement automation of the manual rollback (that
sounds feasible)



On Apr 16, 2011, at 1:29 PM, Nevin Pratt wrote:

Sebastion, that is *exactly* what I initially did at Bountiful Baby.
However, it has been several *years* since I've had to do your #4, so things
have changed slightly since.

Bountiful Baby is an eCommerce site, and the critical "object graph" (your
#2, below) information consists of inventory data (the website keeps track
of our inventory), and gift certificate data (for gift certificates that
have been issued).  Also, whenever either of those datums change, the
website sends an email-- for example, emails are (obviously) sent for each
order accepted, and, it sends emails when it issues a gift certificate.  So,
it is easy to discover (via the emails) what data was lost since the last
image crash.

Consequently, currently this is what happens:

1. image is saved from time to time (usually daily), and copied to a
separate "backup" machine.
2. if anything bad happens, the last image is grabbed, and the orders and/or
gift certificates that were issued since the last image save are simply
re-entered.

And, #2 has been *very* rarely done-- maybe a two or three times a year, and
then it turns out it is usually because I did something stupid.

For us, it's a whole lot easier to do persistence this way than bothering
with any persistence mechanism.  And, it turns out, it is *very* reliable,
with exactly one easily fixable glitch:

The glitch is: occasionally the production image UI will freeze, for no
known reason.  It doesn't effect Seaside, though, so the website keeps going
just fine.  And, if we run the "screenshot" app (in the configuration
screen), there is a link at the top for "Suspend UI Process", and "Resume UI
Process".  Just suspend and resume, and the UI becomes unstuck.

We've been doing persistence this way for years now, and I've been
*extremely* impressed with the reliability.

Before that, we used PostgreSQL and GLORP for persistence.  But I yanked
that code out years ago.  It wasn't worth the bother maintaining it.

If you have a daily image save, then on average there will be 12 hours of
lost data on a "random" crash.  Re-entering 12 hours of orders and/or gift
certificates (discovered from the emails, as mentioned above) might take 10
to 15 minutes.  Not a big deal at all for us.

Ten years ago I wouldn't have even considered doing persistence this way,
but I've changed.  Squeak has changed.  Seaside has changed.  And all for
the better.

Nevin



Given that you don't need transactions, to make that style work, I suggest
this:
1. save the image from time to time (as best suits your needs) like you're
doing now
2. use a secondary way to dump the object graph
3. use the normal image for as long as things are good
4. when shit happens you "transplant" the object graph into a new
"reincarnation" of your app in a fresh image
5. repeat
For dumping the ODB you have options: image segments, SIXX comes to mind now
If you make for yourself some "rescue" kit (script, tools, preloaded code in
fresh image), you can make 4 quite painless (or, why not, monitored and
automated)
sebastian
o/


On Apr 16, 2011, at 12:23 PM, Michal wrote:

hi -

Despite the warnings, I am really interested in sticking to the
simplest way of saving my seaside application data, ie periodically
saving and backuping the image. The seaside book states that

"saving [the image] while processing http requests is a risk you
want to avoid."

What is the status on that? Is that something we can fix? I have been
running an image in this mode for a few weeks, with no ill effect so
far, but I have had major problems with old image/vm combinations. So
is this something that might be fixed already?

Also, I recall that Avi had made a number of attempts at having an
image saved in a forked background process, eg

http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-October/095547.html

did anybody pick up on this, or did anything come out of it?

thanks,
Michal
_______________________________________________
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

_______________________________________________
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

_______________________________________________
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





--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
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

_______________________________________________
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

_______________________________________________
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


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

Re: saving an image while serving

Nevin Pratt



I just didn't get Nevins approach. On the one hand he has everything in his image on the other hand he can "pull back in data" after experiencing a crash. That doesn't fit in my head. Nothing more I wanted to know.

I don't know how Nevin does the "pull back in data" but if you wan't an idea to start visualizing that happening think a SIXX dump being read in a fresh image. There is even a guy that worked on a way to do that streaming the XML to dump big data.

Another idea is ReferenceStream.



Remember, the primary data I "pull back" is inventory control data.  In other words, if the image crashes, the inventory needs to be adjusted for the orders that were placed since the last image save.  So, the question is: how is this done?

To answer that, please remember that the website sends emails for every order placed.  For each order, it sends a total of six different email accounts the order details-- one is an email to the customer with their order confirmation, and five of them are internal Bountiful Baby email accounts used for various control purposes (incidentally, we also run our own email server, so any emails sent to any internal email account never leave our internal network-- not that it would matter, though). 

For those "control" emails, it is trivial to have the website include a simple URL in the email sent to one of the control accounts that, when clicked, replays the order.

So, if the image crashes, I go grab the last backup image (which is usually just a few hours old).  I note the timestamp on the backup, and then I look at the orders that were generated since that time.  And then a few clicks later-- it's all re-entered.

Folks, remember, if your Seaside application is sending emails every time it does something that effects the data in the image, those emails *become* your log history record.  And, it is trivial to include whatever URL you want in one or more of those emails to accomplish any kind of data replay you need.  So, just grab the last backup, click on some emails, and you are back in the game.

It is so darn simple, it's crazy.  :-)

And it works.  Just fine.  Plus, I rarely need it, because it is so darn stable anyway.

We actually also have a similar interface for our Endicia program for generating shipping labels, customs forms, and package postage.  The website includes a different (but simple) URL in the email it sends to the email control account going to the label/postage computer.  While sitting at the label/postage computer, folks click that link in the email, and the label (with postage) is automatically generated for that order.  All via a URL in the email.  And, (almost) nothing is ever hand-entered.

Nevin


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

Re: saving an image while serving

Nevin Pratt
In reply to this post by sebastianconcept@gmail.co

> Not working the way Nevin does. But that's not the Nevin's case. He's saying
> this "yes is one image, yes if it crashes we need to rollback, yes that
> architecture doesn't scale horizontally so what? is enough for the business it
> get us there just fine." (Nevin please correct me if I'm wrong)
>

You are exactly right.

And for Seaside, I don't think our case is very unique.

Your case sounds quite a bit different, though.

Nevin

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

Re: saving an image while serving

sebastianconcept@gmail.co
Yes because we couldn't sleep if it wasn't scalable like hell yah! by design :)

have fun

o/



On Apr 18, 2011, at 2:26 PM, Nevin Pratt wrote:

>
>> Not working the way Nevin does. But that's not the Nevin's case. He's saying this "yes is one image, yes if it crashes we need to rollback, yes that architecture doesn't scale horizontally so what? is enough for the business it get us there just fine." (Nevin please correct me if I'm wrong)
>>
>
> You are exactly right.
>
> And for Seaside, I don't think our case is very unique.
>
> Your case sounds quite a bit different, though.
>
> Nevin
>
> _______________________________________________
> 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: saving an image while serving

NorbertHartl
In reply to this post by Nevin Pratt

Am 18.04.2011 um 19:25 schrieb Nevin Pratt:

> Folks, remember, if your Seaside application is sending emails every time it does something that effects the data in the image, those emails *become* your log history record.  And, it is trivial to include whatever URL you want in one or more of those emails to accomplish any kind of data replay you need.  So, just grab the last backup, click on some emails, and you are back in the game.
>
> It is so darn simple, it's crazy.  :-)

Thanks Nevin for clarifying it. The emails are the missing link I tried to inquire. That is a really good solution and you have a client for it at no cose: your mail client. Great!

Norbert

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

Re: saving an image while serving

Bob Arning
In reply to this post by Philippe Marschall
Sounds like an interesting problem.

On 4/18/11 9:42 AM, Philippe Marschall wrote:
It's not possible for SqueakSource, not without serious effort. The
last time it was done "interesting" issues popped up like the object
format of Timestamp changed. And supposedly fast import/export
mechanism like SmartRefStream become unusably slow.

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

Re: saving an image while serving

NorbertHartl
In reply to this post by sebastianconcept@gmail.co

Am 18.04.2011 um 19:50 schrieb Sebastian Sastre:

> Yes because we couldn't sleep if it wasn't scalable like hell yah! by design :)
>
>
Sebastian,

I think you made it bigger then it was intended by anyone. I was just saying that the proposed solution cannot work without keeping external state. An email account with prepared emails is equivalent to a replay log. So you have snapshots and replay logs. That not only makes it a database (an email account is one) but one with a solid approach. I'm glad Nevin clarified it so everybody can see how simple a smart solution can be.

To assume things is one choice. To explain it is a better one. At least in my opinion.

Norbert

> On Apr 18, 2011, at 2:26 PM, Nevin Pratt wrote:
>
>>
>>> Not working the way Nevin does. But that's not the Nevin's case. He's saying this "yes is one image, yes if it crashes we need to rollback, yes that architecture doesn't scale horizontally so what? is enough for the business it get us there just fine." (Nevin please correct me if I'm wrong)
>>>
>>
>> You are exactly right.
>>
>> And for Seaside, I don't think our case is very unique.
>>
>> Your case sounds quite a bit different, though.
>>
>> Nevin
>>
>> _______________________________________________
>> 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

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

Re: saving an image while serving

Philippe Marschall
In reply to this post by Bob Arning
2011/4/18 Bob Arning <[hidden email]>:
> Sounds like an interesting problem.

No, it's not. It's not what you want to spend your time on. It's not a
problem you want to have.

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

Re: saving an image while serving

Bob Arning
How could you know what I want to spend my time on?

Cheers,
Bob

On 4/19/11 1:07 AM, Philippe Marschall wrote:
2011/4/18 Bob Arning [hidden email]:
Sounds like an interesting problem.
No, it's not. It's not what you want to spend your time on. It's not a
problem you want to have.

Cheers
Philippe
_______________________________________________
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: saving an image while serving

Boris Popov, DeepCove Labs (SNN)
Of course we cannot know with certainty, but generally, given all the other interesting and important problems to worry about, this one seems like a bit of a downer.

Sent from my iPhone

On 2011-04-19, at 6:14, "Bob Arning" <[hidden email]> wrote:

How could you know what I want to spend my time on?

Cheers,
Bob

On 4/19/11 1:07 AM, Philippe Marschall wrote:
2011/4/18 Bob Arning [hidden email]>:
Sounds like an interesting problem.
No, it's not. It's not what you want to spend your time on. It's not a
problem you want to have.

Cheers
Philippe
_______________________________________________
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

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

Re: saving an image while serving

Bob Arning
I guess that's part of what makes it so appealing. ;-)

Cheers,
Bob

On 4/19/11 8:17 AM, Boris Popov, DeepCove Labs wrote:
Of course we cannot know with certainty, but generally, given all the other interesting and important problems to worry about, this one seems like a bit of a downer.

Sent from my iPhone

On 2011-04-19, at 6:14, "Bob Arning" <[hidden email]> wrote:

How could you know what I want to spend my time on?

Cheers,
Bob

On 4/19/11 1:07 AM, Philippe Marschall wrote:
2011/4/18 Bob Arning [hidden email][hidden email]>:
Sounds like an interesting problem.
No, it's not. It's not what you want to spend your time on. It's not a
problem you want to have.

Cheers
Philippe
_______________________________________________
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
_______________________________________________ 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: saving an image while serving

Boris Popov, DeepCove Labs (SNN)
There's a special place in geek he..^^..aven for folks who enjoy working on these kinds of issues for no good reason ;)

Sent from my iPhone

On 2011-04-19, at 8:23, "Bob Arning" <[hidden email]> wrote:

I guess that's part of what makes it so appealing. ;-)

Cheers,
Bob

On 4/19/11 8:17 AM, Boris Popov, DeepCove Labs wrote:
Of course we cannot know with certainty, but generally, given all the other interesting and important problems to worry about, this one seems like a bit of a downer.

Sent from my iPhone

On 2011-04-19, at 6:14, "Bob Arning" <[hidden email]> wrote:

How could you know what I want to spend my time on?

Cheers,
Bob

On 4/19/11 1:07 AM, Philippe Marschall wrote:
2011/4/18 Bob Arning [hidden email][hidden email]>:
Sounds like an interesting problem.
No, it's not. It's not what you want to spend your time on. It's not a
problem you want to have.

Cheers
Philippe
_______________________________________________
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
_______________________________________________ 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

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

Re: saving an image while serving

Bob Arning
Ah, but enjoyment *is* a good reason.

Cheers,
Bob

On 4/19/11 8:33 AM, Boris Popov, DeepCove Labs wrote:
There's a special place in geek he..^^..aven for folks who enjoy working on these kinds of issues for no good reason ;)

Sent from my iPhone

On 2011-04-19, at 8:23, "Bob Arning" <[hidden email]> wrote:

I guess that's part of what makes it so appealing. ;-)

Cheers,
Bob

On 4/19/11 8:17 AM, Boris Popov, DeepCove Labs wrote:
Of course we cannot know with certainty, but generally, given all the other interesting and important problems to worry about, this one seems like a bit of a downer.

Sent from my iPhone

On 2011-04-19, at 6:14, "Bob Arning" <[hidden email]> wrote:

How could you know what I want to spend my time on?

Cheers,
Bob

On 4/19/11 1:07 AM, Philippe Marschall wrote:
2011/4/18 Bob Arning [hidden email][hidden email]>:
Sounds like an interesting problem.
No, it's not. It's not what you want to spend your time on. It's not a
problem you want to have.

Cheers
Philippe
_______________________________________________
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
_______________________________________________ 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
_______________________________________________ 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: saving an image while serving

Peter Kwangjun Suk
In reply to this post by Robert Sirois
On Sat, Apr 16, 2011 at 10:43 AM, Robert Sirois <[hidden email]> wrote:
>  There's sandstonestone db (with the GOODS backend).

Is there a SandstoneDB with GOODS howto?

--Peter

--
There's neither heaven not hell,
save what we grant ourselves.
There's neither fairness nor justice,
save what we grant each other.
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
123