Nat - while I sympathize with your ideas: 1. It's Andrey's show not mine nor yours 2. The rules engine isn't written in Java - as best I can tell probably Delphi 3. It kills offline usage for most us (I fly and travel a lot often without Wifi access) 4. Latency kills - if you're relying on data server, its slow or far away no data.
I could possibly imagine some form of api that is access on the cloud server that would allow other developers to build MLO related applications. That would have the elegance of making the cloud service more popular for Andrey which means more subscribers. Added bonus Kitus or some other enterprising MLO consumer could right MLO to run against this. Cheers Mark On Mon, Dec 10, 2012 at 4:58 PM, Nat Gross <[email protected]> wrote: > Mark, I was about to start a new thread on MLO re-design for some time now > and your post has finally prompted me to do so. > Besides Mac/Linux problem, many other problems would be bypassed as well > with the following proposal. > > In short: > 1. The ingenious rules engine (and database) should > be completely decoupled from the GUI and reside on an Application Server. > 2. Andrey should create an API that allows access to the DB and RE > (RE=Rules Engine). It is OK to keep this API private just for the MLO team. > As time goes along, MLO can decide what functionality to expose to other > developers or end users. (Remember The Milk does this.) > 3. The front end gui needs very little brains. Basically gets the status > from the RE server. > 4. Besides other benefits, this approach would ELIMINATE the need to sync > since all guis are reading back end data -live-. > 5. MLO pricing can be adjusted to the new model which hopefully would make > everyone happier. > > Now, let me extrapolate a bit. > 1. Andrey knows Java. Port the rules (sans gui) to Java. (If not yet in > Java.) Deploy RE (and DB) on Java App server. *Calls to the App Server > can be in any language via SOAP or XML. * > 1b. This would allow deployment to any cloud and gain all those benefits. > 1c. All of a sudden we have project collaboration in MLO. > > 2-3. Build gui's in *any language* *AND platform* you like. Many > programmers can work on different gui's at the same time. Much LESS work > required since all the brains need not be rewritten. Open up limited parts > of the API to anyone. How about an open source gui project? > 2-3b. An HTML5 gui (now possible due to App server) would solve all cross > platform problems, just like that<snap fingers>. > 2-3c. Andrey can focus on the rules and db engine(s) to make it even > smarter (possible?), better, faster, whatever. (Of course Andrey reserves > the right to write a gui:) ) > 2-3d. Multiple types of gui's can be built. You can have a mini gui, a > maxi gui, or whatever gui you wish. Simple stuff. > 2-3e. You can have a Java gui which is multi platform automatically, > > 4. Now, the Android version, which is currently crippled, can utilize all > the benefits of the desktop version. (Because the rules run on the RE > server.) > 4b. Sync? What is that? Oh, if you are off line. Ok, for those situations > we have sync, using existing technologies. In today's world however, 99% of > MLO is used while online anyhow. No sync necessary. Major > headache eliminated. More time for other goodies. > 5. New pricing scheme with many new possibilities. > 6. Doable in much shorter period of time. > > I have much more to say about this but need to go now. > > nat > member of MLO_BETA. > > > > On Tue, Dec 4, 2012 at 4:23 PM, Mark Levison <[email protected]> wrote: > >> There are frequently requests to create MLO for Mac. Let me help you >> understand how complex this would be and why I hope Andrey never does it. >> >> MLO Windows is written in Delphi (aka Object Pascal - >> http://en.wikipedia.org/wiki/Object_Pascal) - the Borland Version >> (presumably Embarcadero now). While it turns out that you can compile >> Delphi for the Mac that doesn't mean it would easy (or sensible to port). >> >> Fundamentally a program like MLO is made from 4-5 parts >> - GUI - which involves working with the windowing system >> - Rules Engine - handles the tasks themselves and all of the rules MLO >> this the real power of the application >> - Synchronization Engine - the bit that speaks to the internet, wifi etc >> - File System - the bit that saves MLO files, archives etc. >> - Extraneous bits - talk to Outlook etc >> >> When trying to port to a Mac (or Linux) we have to ask what would come >> over for free (or with little pain): Rules Engine and Synchronization >> Engine are the only parts that are likely compatible out of the box. >> >> The Mac file system is a bit different than Windows (.DStore, storage of >> preferences, etc.) that would take a fair amount of work to port. However >> that's not the hard part. The kicker is the GUI - the Mac windowing system >> is very very different - it would be a complete rewrite from scratch. >> Finally I just can't imagine the pain in trying to figure out how to port >> Outlook sync etc. >> >> So its simple MLO **might** recompile on a Mac but we're talking several >> years for team to build a GUI that is anywhere near close to Windows - is >> that where we want Andrey and his merry band to spend their time? If it is >> are you personally prepared to fund 2-3 person years of work - I'm not. >> >> Or would you rather that Andrey created a better Windows product, IPad >> (Objective C)/IPhone (Objective C)/Android(Java) >> >> Yes there are other strategies but they all have the same basic problems. >> >> FYI This assumes a simple MLO architecture clear separation of concerns >> etc. In addition Andrey has never told me anything about the architecture >> or anything else - I'm just working off of comments made on list over the >> years. >> >> If you really think that a Mac product matters then help create a >> Kickstarter project to fund its development. >> >> Off to help some people understand Scrum ( >> http://agilepainrelief.com/notesfromatooluser/2012/11/learning-scrum-through-games-golidocks-iteration-ii.html >> ) >> >> Cheers >> Mark Levison >> Agile Pain Relief Consulting<http://agilepainrelief.com/notesfromatooluser>| >> Writing <http://agilepainrelief.com/notesfromatooluser/> >> Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> Nov >> 28, Toronto <http://www.torontoagilecommunity.org/display/PUBLIC/Home>26 and >> Montreal <http://agilemontreal.ca/agile-tour-2012/> 24 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "MyLifeOrganized" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/mylifeorganized?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "MyLifeOrganized" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/mylifeorganized?hl=en. > -- Cheers Mark Levison Agile Pain Relief Consulting <http://agilepainrelief.com/notesfromatooluser> | Writing <http://agilepainrelief.com/notesfromatooluser/> Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> Nov 28, Toronto <http://www.torontoagilecommunity.org/display/PUBLIC/Home> 26 and Montreal <http://agilemontreal.ca/agile-tour-2012/> 24 -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
