Feasibility Study for Potential fP Software - Part #3 (final for the day)

[Keith' Weatherhead]

Fairlight wrote:

> Is it just me, or did Jay Ashworth say:
> 
>>On Sat, Sep 16, 2006 at 12:37:40PM -0500, Keith' Weatherhead wrote:
>>
>>>In thinking as much as I would like to say implement on anything 
>>>from 5.0 onward, I do not think you would want to go back to 4.8 and 
>>>I am thinking that you might want to restrict it 5.6 forward, 
>>>especially if you can get the missing features (@delete  and @time 
>>>w/ additional granularity).
> 
> Yes, because they've been -so- good at listening to requests over the years
> that an officially bug-reported default mode 0666 on EXPORT files from
> -three- years ago has yet to be resolved.  If they can't change two bytes
> in a mode when opening a file, what again are the odds that I'm going to
> get @delete implemented when -I- don't even buy their software?  :)  My
> clients do, I don't.  Ergo, I don't technically exist to them.

True, which means you might have to do it the long way without an 
@delete.  You said you had ideas, mine would require the FP 
application programmer to call the functionality for logging prior 
to doing the delete.  What about a failed I/O?

>>>Additionally, I would think that you are going to want to require at 
>>>least one if not two dedicated indexes that could be hidden for the 
>>>transaction system.  Now that there are 26 indexes with 5.6 you 
>>>could require say index Y and Z be devoted to the transaction system.
>  
> The idea is to be as non-intrusive as possible, really.  I've got so many
> variations on models in my head right now, it's not funny.  And more since
> reading your posts.

Which is why I suggested 5.6 as that just added the extra indexes, 
many people wanted more than 16, if they need more than 24 (leaving 
two for your processing) then maybe FP or the implementation of 
their application needs review?

> Can I assume by time delta, you're simply talking timezone offsets from GMT
> so that you can run a system in EDT and one in PDT and adjust the data so
> that it's the same at the time level?  Or are you talking time delta as far
> detailed (in the transaction log you're mentioning) as what NTP would give
> you for an offset?  I'm thinking the former, as I see no need for anything
> as accurate as the latter, given the fact filePro itself doesn't track
> things that accurately.  Just making sure...

What about servers that are more than a minute off, time clock wise. 
  The reasons could be varied, but in a transactional environment... 
seconds are years, especially in a heavily used environment.  I came 
out of a shop that had anywhere from 3,000-4,000 users logged on, 
probably better than 16 hours a day.  At any given time 300-400 were 
hitting the enter key.  The mainframe usually had the equivalent in 
modern day process reporting anywhere from 1,200-1,300 tasks at 
light periods and over 2,000 in peak periods.  Our databases were 
stripped over 8 drives for smaller ones and over 16 drives for 
larger ones.  There were around 88 disk drives as I recall on the 
machine.

> Interesting point, though.  I hadn't thought about maintaining the
> system-maintained fields like @CD, et al.  Don't ask why, but I wasn't
> thinking about the headers; I was thinking about purely the user data.  But
> I agree (and that was really helpful advice already in this discussion)
> that one would need to preserve all the system maintained fields one could.
> That said, those aren't actually settable from inside fP processing, are
> they?  You can't actually -change- @CD, for example, can you?  If not,
> we're down to rewriting key and data segments--and worse, indexes--from the
> ground up, which is a flat-out non-starter.  The idea was to do most of
> the work inside fP itself.  If the fP-API that never materialised (after
> what, two years now?) isn't there to be used, I can -not- see writing what
> amounts to a clone of fP's internal engine just to do this.  Then I'm going
> to agree with Jay and say it's really not the way to go about it.

Writing indexes, should not be required.  The best answer from FP 
would allow you to do a write supplying the reserved fields, with 
proper permissions, of course.

I took it that you wanted to use FP to manage the data, but I think 
there will have to be a couple of external processes, but in my way 
of thinking they would be supporting, and not replace the FP engine.

Once the record is written, the header can be read by another 
process and simply pick up the 20 byte header, however, there would 
be a window of opportunity for another process to take a read/write 
of the record.  The only true way to protect this is to have FP 
return a system array, post write, of the entire record.  You could 
construct the header, everything except the freechain pointer if it 
needed to be changed on a record that was written from available to 
used.

[deleted, Jays and Marks ODBC exchange]

> I'm trying to condense the thread a bit, here.  I'm curious why the mixed
> financial viability rating from Keith.  On one hand it wouldn't be worth
> much, and on the other it would eventually be worth a lot?  That seemed a
> bit contradictory.  Unless it's based on initial vs mature.  As I see it,
> you can't really screw around with something like this--it's going to have
> to be right as possible straight off or it's not worth having.

The amount of sites that would be interested  AND  would pony up 
dollars.  I suspect there are a few, whether they would want to 
defray the development is another issue.  Possibly if you could line 
up two or three, that would pay for the initial development and then 
get a small cut, reducing their outlay if other copies got sold? 
They would have to agree that if no other copies were ever sold, 
they are in for what they spent.

[deleted more financial thoughts from Mark]

I'm not disputing your development thoughts from a financial impact, 
I just don't see it as a way to retire.  As I said about, with the 
right specification... do you think you could get multiple sites to 
agree to fund/purchase?  If not... it is a "personal, spare time, 
bragging rights project" as I said in a earlier post.  Personally, I 
wouldn't be worried about calls from a lawyer at this time.

I would try to put a small mock-up together and determine if it 
*could*  be made solid enough to offer to others.  Skip the FP 
record headers, time deltas, etc.  As I laid out in my first post, 
the Transaction Logging and Recovery is truly the heart. Everything 
else gets built on top of those pieces.  If you cannot make that 
work reliably, the rest won't be worth anything to anyone, period.

As I said, I'm interested, I had started to do this myself years ago 
and didn't have the time to devote to it for one, and wanted the 
items that I mentioned so I could make it solid if I was going to 
invest into a project like that.  I never thought about doing it 
other ways, especially across platform compatible.

> mark->
Regards,
Keith
-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
Keith F. Weatherhead                   keithw at ddltd.com

Discus Data, LTD                  Voice: (815) 237-8467
3465 S Carbon Hill Rd               Fax: (815) 237-8641
Braceville, IL  60407       Nat'l_Pager: (815) 768-8098
- - - - - - - - - - - - - - - - - - - - - - - - - - - -