Small MLO re-design; Huge gains.

[Nat Gross]

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 <ma...@mlevison.com> 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 | Writing
Proud Sponsor of Agile Tour Gatineau Ottawa Nov 28, Toronto 26 and Montreal 24

--
You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group.
To post to this group, send email to mylifeo...@googlegroups.com.
To unsubscribe from this group, send email to mylifeorganiz...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.

[m...@grantsmiths.org]

Nat: Interesting approach and one worthy of some discussion. But I want to immediately resist the suggestion that 99% of MLO is used while online anyhow. It's certainly not true for me. If a redesign were to make offline usage difficult or awkward, I would find myself paying high fees for data network usage whenever I'm out of wifi range, which is often. That would be a dealbreaker for me.

-Dwight

[Stéph]

And I work offline *a lot* of the time. I need my data and functionality on my devices rather than online.

Interesting idea, but it would be a deal-breaker for me. Now if the non-GUI elements were on my local device, I wouldn't have a problem with decoupling them from the GUI.

Stéph

[Nat Gross]

Hi Dwight;

I agree that 99% is an exaggeration -for now- but we are getting closer to that as more wifi hotspots become easier to access for free for a variety of reasons.

Of course in my scheme of things current syncing technology would still be available, but would not need be upgraded to newer technology.

-nat

[Mark Levison]

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

--

[Dwight]

Interesting that Evernote's businesses model is the opposite of Mlo's; Evernote gives you the cloud storage for free and charges for an offline copy. I'm okay with that off the synch process is fast, automatic and effective.

[m...@grantsmiths.org]

 

I agree that hotspot proliferation has been rapid but I think it's slowing down. Growth may continue to be rapid in the air travel business but a lot of the places without wifi (my car, my yard, my bedroom) have no plans to provide it in the foreseeable future.

[Nat Gross]

On Mon, Dec 10, 2012 at 6:28 PM, Mark Levison <ma...@mlevison.com> wrote:

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.

1. Of course. Hopefully he is reading this.

2. Even if not written in Java:

    a) Andrey knows Java. He also knows the problems he is up against with 4.0 and beyond. It is his decision if to rewrite in Java. Since both languages use the OOP paradigm, and he knows both, it might be the best route. Quicker than alternatives.

    b) I don't know Delphi. But maybe the same concept (back end server) is available there. 

3. Offline usage would be the same . The same SQLlite db currently used can be synced with the server (using new api) before/after going offline.

4. In addition to being a MLO pro and cloud subscriber, I am also a RTM (Remeber The Milk) pro customer. All the data is stored on their cloud. I can tell you it flies! Usually less than a second to update tens of todo's.

4b. Don't forget that the data server itself can be on an Amazon ews or competing cloud. It is FAST.

nat

[Mark Levison]

One last thought - many of us (myself included) see grand ideas for MLO as we make this wonderful suggestions we have to remember that MLO is small company that is funded from application sales. As we compare it to Evernote (or other big players) these are venture (or vulture) backed companies. Their focus (for legal reasons :-) is making their vultures happy first, the users are only important as long as they vultures are happy.

Back to making development teams happier.

Cheers

Mark - a human

--
You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group.
To post to this group, send email to mylifeo...@googlegroups.com.
To unsubscribe from this group, send email to mylifeorganiz...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.