checking custom prop data integrity

[Andre Garzia]

now I'll go into "consultancy" mode and talk a while about my opinion:

both product and service have one very expensive thing people often forget,
which is support. How high is your cost to support your user. There are
services and products which offer no support whatsoever, this is really
cheap! Others will go like a community approach and have a wiki and forums,
this leads to good documentation and healthy relationships in the long run.
Or you can answer support calls directly and that is time and money
consuming.
The big gotcha between product
or service is the cost of patching. If there's a bug or an upgrade,
how you dance? With a centralized service, it's easier, you upgrade
the service and that's done. With applications distributed everywhere,
things can get tricky, for example, if you change the MySQL schema and
someone doesn't upgrade to deal with the new database, now what?!

People often look into application vs service with the following
approach: product is a one time payment and service is a subscription
and will decide based on that. I think more important than that is how
much will it cost you to maintain and support your users. Applications
for example have installation issues on the other hand, services with
little users are not profitable.

anyway, thats how I do it, I think on the cost of keeping something
running more than how much it will give me.

andre



On Tue, Jul 21, 2009 at 3:22 PM, George C Brackett
<gbrackett at luceatlux.com>wrote:

> Ah, I see.  I guess one option would be to offer as a service to maintain
> the data on a MySQL database on your own server, but you may not wish to get
> into such a long-term relationship.  I have often thought about the balance
> between offering  product and offering a service, and it's not obvious to me
> which might be better in general -- only in particular.
>
> George
>
>
> On Jul 21, 2009, at 1:50 PM, Phil Davis wrote:
>
> George C Brackett wrote:
>
>> Is the purpose of the online stack just to hold the value of the custom
>> property?  If so, why not use a database such as MySQL or PostgreSQL?  These
>> are carefully engineered to prevent collisions by multiple users.
>>
>> George
>>
>
> You're absolutely right, George - MySQL etc offer superior data management
> capabilities. But often the introduction of a conventional DBMS brings with
> it the need for more technical support. Most small businesses (at least the
> ones this product serves) don't have a tech support person on the payroll
> and want to keep it that way. By using this simple dumb-data-on-server /
> smart-app-on-every-client approach, even the owner of the company can
> usually restore the server data if something goes wrong! Imagine that. ;-)
>
> Phil
>
>
>> On Jul 20, 2009, at 7:59 PM, Phil Davis wrote:
>>
>> I'm looking for the best way to detect data corruption ASAP after it
>> happens in a custom property of a stack. The stack resides on a file server
>> and is read & written by many clients. File locking during reads and writes
>> is already in place and seems to be doing its job, but occasionally we still
>> have data corruption that creeps in.
>>
>> Specifically, I want to make a way for the "Client B" app to know that the
>> value it gets from the "uData" custom property of stack "myStack" is exactly
>> what the "Client A" app put there a moment before.
>>
>> Here's how I see this working:
>>
>>  * Client A
>>       o (stack is in memory, file is locked on server)
>>       o sets the uData of stack "myStack" to new value
>>       o puts md5digest of updated uData into "dataDigest" file on server
>>       o saves "myStack" stack
>>       o deletes stack from memory
>>       o unlocks file on server
>>  * Client B (a moment later)
>>       o locks "myStack" file on server
>>       o puts "dataDigest" file from server into tOldDigest
>>       o goes to stack "myStack"
>>       o puts md5digest of uData custom prop into tNewDigest
>>       o if tNewDigest = tOldDigest, all is well; otherwise
>>         corruption exists
>>
>> Does anyone see a problem with this approach? Is there a better way to
>> accomplish the goal? If each client could check the data after its own write
>> without having to read the stack into memory again to do so, that would be
>> great - I just didn't see a way for that to happen.
>>
>> Thanks everyone -
>>
>
> --
> Phil Davis
>
> PDS Labs
> Professional Software Development
> http://pdslabs.net
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



-- 
http://www.andregarzia.com All We Do Is Code.