couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Lane <jasonlane...@googlemail.com>
Subject Re: A Call to Arms: Fighting the SharePoint/SQL Mobile Development Stack
Date Mon, 18 Apr 2011 13:30:07 GMT
On 18 April 2011 13:53, Chad Cross <chadcross@gmail.com> wrote:

> It's encouraging that you were able to propose that sort of solution at
> such
> a company.
>
> I have a surprise meeting in 4 hours to discuss "solutions".  I think this
> may be an admittance that SharePoint is not the right solution for what we
> want, but unfortunately I don't have much of anything to show in such a
> short period of time.
>
> Here is the basic usage scenario:
>
>   1. Technican approaches downloads building information/ticket information
>   to his/her mobile for a service request.
>   2. Technican enters building and no longer has connectivity to the remote
>   server
>   3. Technican enters data on their mobile about the work they've completed
>   (assuming this is HTML/JS based, the local data store could be used to
>   temporarily store this data?)
>

Absolutely. This is another are I have worked on. especially if the devices
are iOS / Android HTML5 is a given


>   4. Technican returns to coverage area and needs to send their data back
>   to the remote server (by all accounts we have to create our own conflict
>   resolution system if the records the Technican wishes to update have been
>   updated while they were out of coverage)
>
> I'm sure this is small potatoes for the community at large to explain to
> one
> another, but what's the proper way to discuss this with peers/superiors
> that
> are completely stuck in a .NET mindset?
>

Technological debt!


>
> Thanks everyone!
>
> -Chad
>
> On Fri, Apr 15, 2011 at 3:08 PM, Jason Lane <jasonlanexml@googlemail.com
> >wrote:
>
> > Why don't you look at non-blocking architecture throughout the stack. I'd
> > recommend looking at Couchdb & Nodejs. I gave a presentation at work
> > recently on concurrent, non-blocking, event based architectures at my
> work.
> > I work for Thomsonreuters, big lumbering corporation that it is.
> >
> > sent from my Nexus S
> > On Apr 15, 2011 1:58 PM, "Chad Cross" <chadcross@gmail.com> wrote:
> > > All,
> > >
> > > I'm in the middle of what could be a very interesting opportunity for
> my
> > > company and I'm in need of assistance.
> > >
> > > Our accounting system, Microsoft Dynamics SL, is central to everything
> we
> > > do. Right now we have a need for a mobile app that interacts with a
> very
> > > small subset of data stored in this system. Currently, others in my
> tiny
> > IT
> > > department are pushing hard and evaluating a solution that involves
> > > SharePoint 2010 (which we already own) for hosting, InfoPath for form
> > > creation, and 3rd party wrappers that allow the "application" to be
> > accessed
> > > via Android, Windows Mobile 6.5, and iOS. Those wrappers include Mobile
> > > Entree <http://www.mobileentree.com/>,
> > > SharePlus<http://www.southlabs.com/detail.aspx?id=SharePlus>,
> > > and others that they discover every day.
> > >
> > > Their biggest concern is concurrency. The idea that a service
> technician
> > > could be in the field and interacting with the software to pull down
> > > information about a specific trouble ticket, walk into an area without
> > > coverage, and still be able to input data. When they return to
> coverage,
> > > the app should handle pushing that data back to the database without
> > > encountering concurrency issues.
> > >
> > > I'm sure some of you have experience battling suits when it comes to
> > > proposing alternative solutions (and in my case, "alternative" means
> > > non-Microsoft), so I would like for anyone that has experience with
> > CouchDB
> > > and MS-SQL interaction to please chime in!
> > >
> > > Thanks!
> > >
> > > -Chad
> > >
> > > P.S. For you Twitter users, please retweet!
> > > https://twitter.com/#!/TheChadCross/status/58871610505039872
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message