Tim,

Well, to be honest the first time I read it, my mind wouldn't see the blank
line and next header at all. It just went "scripts, scripts...".

Any idea what the estimated release date for the next minor release (1.5?)
is, within weeks, months...? Just interested, no pushing

Regards, Harry



"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schreef in bericht
news:546BB5DC-6E72-4537-BDD5-B19C442F682F@news.elevatesoft.com...
> Harry,
>
> << Yeah, I noticed the the two subjects where seperated by a blank line,
so
> I figured........ >>
>
> Sorry, I didn't mean to imply that you were "reading-challenged".  I
usually
> just reiterate things when it might be a mistake I might make.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Hi Tim,

I have not been able to download the DAC from the web site as it keeps
saying that it is being built and should be ready in half an hour.

Are you waiting for the next build or is it an error on the site?

Chris Holland

Harry,

<< Any idea what the estimated release date for the next minor release
(1.5?) is, within weeks, months...? Just interested, no pushing >>

It will probably be around the first week of August.

--
Tim Young
Elevate Software
www.elevatesoft.com

Chris,

<< I have not been able to download the DAC from the web site as it keeps
saying that it is being built and should be ready in half an hour.

Are you waiting for the next build or is it an error on the site? >>

Yeah, it's waiting on the 1.04 B3 build, which I'm finally starting up right
now.  I unfortunately was gone all day yesterday taking care of some
personal things, so I lost a day.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Ok, we hold our breath till August then I think you've made EDB very
good and stable in just a short period. If I look at other products it
sometimes takes ages.

Do you also have a roadmap for future releases after that next minor
release? Although the only thing that I can think of missing is full RI, or
are there more things to come?

Regards, Harry

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schreef in bericht
news:1635B546-F999-43B8-99B8-CB8EC8A4B404@news.elevatesoft.com...
> Harry,
>
> << Any idea what the estimated release date for the next minor release
> (1.5?) is, within weeks, months...? Just interested, no pushing >>
>
> It will probably be around the first week of August.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Hi Tim,

> Thanks very much.  And a general thanks to Kim for the EDB support in
> kbmMW.

You are very welcome... thank you for the oppertunity to do so!


--

best regards
Kim Madsen
kbm@components4developers.com
www.components4developers.com

www.myc4d.com - Your access to cool code

The best components for the best developers
Application server enabling technology for developers

Harry,

<< Ok, we hold our breath till August then I think you've made EDB very
good and stable in just a short period. If I look at other products it
sometimes takes ages. >>

It's the survival instinct.  We can't afford to have a lot of bugs - we
don't have enough personnel to cope.

<< Do you also have a roadmap for future releases after that next minor
release? Although the only thing that I can think of missing is full RI, or
are there more things to come? >>

After that release, I'll be starting full-time on getting the high-end
server product completed.  That will round out the product offering from
top-to-bottom and give us a product for everyone.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

I'm really looking forward to the EDB Linux release(!), and one of the
things I'll be evaluating is the possibility for using it within
machine image instances on Amazon EC2 (http://aws.amazon.com/ec2),
something that might be a good "new market" for you. Along with all the
good things that EC2 offers though, is the "lack of persistence." If a
running instance should go down for any reason (setup or programming
error within the image, power outage, or Amazon virtualization
problem...) the entire virtual machine disappears. Poof, all our data
is gone. No RAID in the "virtual cloud" to pull bits from here; and I'm
a SCSI kind'a guy--this'll require some adjustment in my thinking.
And... VMs going down is not unheard of

Other environments are assembling structures and methods for dealing
with this, mostly by periodically persisting to the Amazon S3 service
(http://aws.amazon.com/s3), especially since bandwidth between the 2
services is free and optimized. But that's sorta, kinda "dead storage."
There's no local-style file access, just object (file) PUTs and GETs,
though one can do partial HTTP GETs.

[There's a decent chance you're not aware of EC2 and S3 yet, having had
your hands and head busy with so much EDB work! So I'll completely
understand if you want to bypass this entire message, or come back to
it at some later date.]

My questions: Is this something that EDB is likely to accommodate "in
stride" and how would you recommend implementing persistence in such an
environment?  Would the existing backup methods lend themselves to
safely and efficiently persisting some pretty important databases
(email, business transactions/records, secure key codes, etc.) on such
virtual machines?  (Sub-question: Is there currently a
partial/incremental backup facility in EDB? [Sorry, I'm not a user
yet...])

I have seen mention of other databases being used within EC2, so I
rather expect that it's possible. I'd just like to get a better sense
for how much reliability and persistence you think that users could
configure into the system, and what trade-offs that might cost us.

Someday when EDB replication is available, one could probably replicate
across multiple EC2 instances, and play the odds, but I don't think
that's available now (?), and I'd like to avoid the situation anyway
for several scenarios.

My guesstimation is that we'd otherwise have to use either a
time-based, or transaction-based (triggered) schedule to do either a
full or incremental backup to S3. So every 20 minutes or 5 important
transactions (...) trigger a backup?...

Thank you.

John,

<< [There's a decent chance you're not aware of EC2 and S3 yet, having had
your hands and head busy with so much EDB work! So I'll completely
understand if you want to bypass this entire message, or come back to it at
some later date.] >>

I'm not aware of them, but from the little I just read, they are probably
not the ideal environment for a database that requires traditional file I/O
access in the OS.   Does the environment offer a traditional storage
mechanism for the applications that you put in the VM ?  Or are they gone
also if the VM goes down ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> I'm not aware of them, but from the little I just read, they are
> probably not the ideal environment for a database that requires
> traditional file I/O access in the OS.

Most definitely not; They're far from ideal. However, there are
features that are inducing quite a few developers to attempt pounding
the square DB peg in the round "fully-virtual(!)" hole.

My first (2nd & 3rd) impression was that this shouldn't even be
attempted... It's better to drive and record all database activity from
real (non-virtual) servers, and leave those virtual servers to process
batch jobs or deal with relatively static secondary databases, or serve
as additional tiers from real DB servers. However, the potential for
quickly bringing up and tearing down additional servers and the
financial benefits etc. has some great appeal. (Though this would
probably be better structured to just connect, cache or replicate
through to real DB servers...)


> Does the environment offer a
> traditional storage mechanism for the applications that you put in
> the VM ?  Or are they gone also if the VM goes down ?

When you want to run these virtual servers you create AMIs (Amazon
Machine Images) which correspond pretty well to full drive images,
complete with specifically configured OS's (limited to Linux 2.6
kernels, and all the applications and data you want, up to 10 GB) which
get stored on their *reliable* S3 service.

When you want to bring up 1 or more servers, you send commands that
grab these images, create virtual machines and start executing them at
which point they're called Instances. The original image from S3 is
"pristine" and not touched. Each instance is given 160 GB (traditional)
local storage by way of a disk drive mounted on /dev/sda2. BUT this
also "evaporates" on both proper or improper exits. (In fact, if not
wiped (or encrypted), I've seen commentary that says you can read the
contents from other people's/instances' prior usage when you bring up
your own instances.) Other currently-described EC2 DB implementations
(using MySQL, PostgreSQL, etc.) are basically periodically backing up
the dynamic DB pieces from that local storage to S3.

The EC2 Service is still in somewhat limited beta. One has to wonder if
they might not add persistent ("normal") storage at some future point,
along with some other important features such as fixed IP addresses...

I still wonder how feasible it would be to use EDB in such situations
with lower priority DBs though... and possibly... later in
high-priority situations with replication through to real (E)DB servers?

Thanks.