the massive mess of current e commerce shops can forth clean it up?

can someone who knows forth well walk in with mr aysan's gforth
appserver and get rid of mysql ruby rails ha proxy nginx passenger
garbage adn tomcat apache oracle garbage and have sultion that is 100x
as lean adn flexible?

seems the mess is so big that is made in these e commerce shop and
even huge shops that forth could not be worse

What, ZenCart does not meet your needs?

Jason

On Jul 13, 7:38*pm, Jason Damisch <jasondami...@yahoo.com> wrote:
> What, *ZenCart does not meet your needs?
>
> Jason

zenwho?

What eCommerce software which has already been written are you familiar with? Let's start the conversation there. There are several popular ones. Why don't they meet your needs? What are you looking for?

Jason Damisch <jasondamisch@yahoo.com> writes:

> What eCommerce software which has already been written are you familiar with?
> Let's start the conversation there. There are several popular ones.
> Why don't they meet your needs? What are you looking for?

If there're several ones in existence, then they have drawbacks, each of them, right?
Consider I'm going to develop a new product to address those drawbacks.
What does Forth offer to help solving this task?


--
HE CE3OH...

On Jul 17, 2:35*pm, Aleksej Saushev <a...@inbox.ru> wrote:
> Jason Damisch <jasondami...@yahoo.com> writes:
> > What eCommerce software which has already been written are you familiarwith?
> > Let's start the conversation there. *There are several popular ones.
> > Why don't they meet your needs? *What are you looking for?
>
> If there're several ones in existence, then they have drawbacks, each of them, right?
> Consider I'm going to develop a new product to address those drawbacks.
> What does Forth offer to help solving this task?
>
> --
> HE CE3OH...

I envision something like in memory data, with updates logged, and
then a data dump every hour or two.
This keeps query fast and lets you lod the dump and read log to update
it to current if pwoer faults.

kinda like prevayler or happstack

> I envision something like in memory data, with updates logged, and
> then a data dump every hour or two.

I don't consider a dump to be a regular function, but an exception to be avoided. If a dump needs to be made every hour, then that is a problem. I only look at the memory if something is going wrong. Then I fix it and then I don't look at the memory.

> This keeps query fast and lets you lod the dump and read log to update
> it to current if pwoer faults.

Query should just be fast without any special tricks. It's the result of a program which does just what it needs to do to get it's job done. The bottleneck should be the hardware, or the other guys' computer.

> kinda like prevayler or happstack

On Tuesday, July 17, 2012 5:35:56 PM UTC-7, Jason Damisch wrote:
> > I envision something like in memory data, with updates logged, and
>
> > then a data dump every hour or two.
>
>
>
> I don't consider a dump to be a regular function, but an exception to be avoided. If a dump needs to be made every hour, then that is a problem. Ionly look at the memory if something is going wrong. Then I fix it and then I don't look at the memory.
>
>
>
> > This keeps query fast and lets you lod the dump and read log to update
>
> > it to current if pwoer faults.
>
>
>
> Query should just be fast without any special tricks. It's the result ofa program which does just what it needs to do to get it's job done. The bottleneck should be the hardware, or the other guys' computer.
>
>
>
> > kinda like prevayler or happstack

So you mean the forth app runs straight from memory. No disk access needed.. What then if power fails? LArry Ellison, a true scumbag, has based a whole idustry around this fearful question.

> So you mean the forth app runs straight from memory. No disk access needed. What then if power fails? Larry Ellison, a true scumbag, has based a whole industry around this fearful question.

I'm sure that there is a way around this problem, but at a price.

J.

On Sunday, July 29, 2012 9:26:15 AM UTC-7, Jason Damisch wrote:
> > So you mean the forth app runs straight from memory. No disk access needed. What then if power fails? Larry Ellison, a true scumbag, has based a whole industry around this fearful question.
>
>
>
> I'm sure that there is a way around this problem, but at a price.
>
>
>
> J.

well www.prevayler.org is one solution

log updates to disk in fast enuf stream

dump whole memory to file every few hours

if faults, relaod dump, replay log

apparently each transaction must be non deterministic which I think means it can be replayed, this part i dont understand yet

time must also be part of the transaction, although my logic says order is more important??

since most of ram is eaten by sloppy interpreters I think forth could win here and most data is on disk in form of blob such as pics n stuff

forth would just have to be coaxed to do string biting to support name based virtual hosts and perhaps sessions, although any apps fork an app that reverse control by then that forked proc call to the client browser for next request, and possibly using continuation which I also dont udnerstand, but which might be part of the prevalent data image anyhow in this setup

supposedly each client then has a proc so the 64 cpu problem is them conquered since the procs cna use N cpu

I am not sure forth liek gforth will use 64 cpu maybe mr paysan can comment

from what mr paysan has posted previously, the forth can easily do string munching