EOI - Linux Developer required

Haarsma, Michael (SAPOL) michael.haarsma at police.sa.gov.au
Wed Jan 10 05:11:58 CST 2007


http://www.howtoforge.net/mysql_master_master_replication

Nice link showing you how to do Master Master replication.

Michael

> -----Original Message-----
> From: linuxsa-bounces at linuxsa.org.au 
> [mailto:linuxsa-bounces at linuxsa.org.au] On Behalf Of David Lloyd
> Sent: Wednesday, 10 January 2007 11:03 AM
> To: Evan
> Cc: lsa
> Subject: Re: EOI - Linux Developer required
> 
> 
> 
> Evan,
> 
> > Thanks for the reply.
> 
> That's ok.
> 
> > Realistically 6 months I think is adequate the backend is trivial in
> > terms of what we need.
> 
> Having worked as a project manager/requirements gatherer for 3 years, 
> I'm always weary of things that appear to be trivial.
> 
> > It's purpose is to consolidate the information
> > from the registers report some sales figures manage operators and 
> > process invoices/transfers from the head office.
> 
> That's not too difficult but it involves:
> 
>   * managing multiple sales figures
>   * managing multiple operators
>   * managing ACL/Roles for operators/store managers etc
>   * managing stock albeit a limited set...
> 
> > We have the Inventory
> > side covered from the head office.
> 
> However, that also means you need to adapt their system to the new 
> system. Whilst having an inventory management system in place 
> certainly 
> reduces the scope, I've found that inventory systems are notoriously 
> complex and it takes a lot of care to adapt them properly.
> 
> > The stores will obviously hold a
> > local inventory but again that's trivial.
> 
> Sorry, but it's not at all trivial. In a previous solution, we 
> implemented it like this:
> 
>   1. MySQL would replicate to the stores from a central server
>   2. A customer web service would operate on the stock levels to a \
>      central server
> 
> MySQL replication isn't two ways yet (you can replicate from 
> master to 
> slave but not from slave to master).
> 
> > Of course nothing is hard and
> > fast and we do not want to sell ourselves short in this.
> 
> Absolutely not - at a minimum you either:
> 
>   1. Have to implement functionality for what you currently have
>   2. Have to come up with a good business case for NOT replicating it
> 
> > We will replace the current system as it's Foxpro based and dos at
> > registers with win98 on back office running in a virtual 
> machine on XP.
> 
> Ouch.
> 
> > I think a prototype could be built within a 2 month period of solid 
> > work
> > then a month fixing it then with the extras taking another 2 months
> > So after 6 months we should have a demonstrable product.
> 
> It would probably take at least a week's absolute solid work to 
> understand enough of what is currently implemented to get an 
> idea of how 
> long a reasonable prototype might take. From such work you'd work out 
> what the prototype would have to do...
> 
> > Given the lack of solid timing I may not go beyond the 
> gathering stage
> > for a month or so.
> 
> Indeed.
> 
> Incidentally, whilst I don't particularly mind, you do realise you 
> broadcast my mobile phone number to the LinuxSA list :P ?
> 
> DSL
> -- 
> LinuxSA WWW: http://www.linuxsa.org.au/ IRC: #linuxsa on 
> irc.freenode.net To unsubscribe or change your options:
>   http://www.netcraft.com.au/mailman/listinfo/linuxsa
> 



More information about the linuxsa mailing list