[I-mobile-u] Opinion about the frameworks

[Sonya Huang]

Marco and others,

Having gotten our feet wet with each of the three frameworks mentioned in
this thread, we at Modo Labs have come up with the following summary.  Being
Modo Labs, our preference is naturally toward Kurogo, the framework that we
develop and actively support, and for which we provide support services.
However, we have tried to keep this summary as balanced as possible, and
welcome further discussion that can help other schools
decide which framework to choose.

Mobile Web OSP, the current MIT Mobile Web, and Kurogo (an implementation of
which Harvard currently uses on production), all originated in some form as
forks of the MIT Mobile Web 0.9 code (henceforth known as the MIT 0.9 code)
that was released on Sourceforge in the spring of 2009.  Each of them has
since evolved in different directions for different purposes, and all have
attempted to address problems present in the 0.9 code (especially
configuration end deployment) in different ways.  However, while implemented
differently each takes ideas from one another.

If you are making a choice among the three frameworks, here are some points
by which you can compare.

*Mobile Web OSP*

Background: First fork of MIT 0.9 that became publicly developed in open
source fashion.  For this reason it is probably the most widely deployed of
the three mobile web frameworks, and most well tested in different
institutions.  It also has the most mature set of documentation.

Mobile Web OSP is very much aimed at organizations that only want to deploy
a mobile web (and not in addition to other interfaces such as native apps
and SMS).  Much of the structural separation between data source libraries
and the modules they represent has been simplified, so that developers for
the most part can just be working in the /web directory.

First-time configuration: At the top level of the tree, copy the file *
config.gen.copy.inc.php* to *config.gen.inc.php*.  Edit the defintions as
necessary.  Point your server to the */web* directory in the tree.

Device classification: Built into the code that generates web content; no
separate server required.

Main strengths:
- Wide deployment
- Openly developed for the longest time
- More documentation
- Incorporation of jQTouch (and eventually jQuery Mobile, which is still
pre-beta) for the Webkit interface.

Main weaknesses:
- Less suitable for use with non-mobile-web interfaces

*MIT Mobile*

Background: The MIT Mobile framework at present includes code for iPhone and
Android native apps in addition to the Mobile Web and its associated Device
Detection service.  The native apps work with a server API that is deployed
along with the Mobile Web.

The MIT server code was originally designed to support two completely
different interfaces, mobile web and SMS (which due to low usage is no
longer in service).  Thus it was quite natural to add an API component for
native apps.  For a mobile web-only deployment, much of the configuration
related to native apps can be ignored, and while the code currently assumes
presence of a MySQL database, it can be easily edited to work without one.
However, support for push notifications in the iPhone app does rely heavily
on MySQL (although supplying different RDBMS backends should be
straightforward), and obviously the developer needs to go through the
standard process of getting a certificate from the Apple Developer Portal.

First-time configuration: Three files need to be edited in the top-level
directory */mobi-config*.  These are *mobi_web_constants.php*, *
mobi_lib_constants.php*, and *mobi_lib_config.php*.  Be careful to look at
all constants, especially those pointing to a location on the local
machine.  Point your server to the */mobi-web* directory in the tree.

Device classification: Hits a separate service running the supplied device
classification code.

Main strengths:
- Open source native apps
- Maintained by the people who did the original MIT Mobile project
- Arguably the most feature-rich of the frameworks, and feature set grows
fast.  Great place to look for ideas.

Main weaknesses:
- A lot of functionality is MIT-specific
- More complex configuration and deployment

*Kurogo Mobile Web*

Background: Originally branched off the MIT v2 code, but has since been
completely rearchitected with an eye toward inheritable templates,
interchangeable data sources, ease of configuration, and a more clear-cut
MVC paradigm.  Developed and maintained by Modo Labs, but is taking
contributions from other institutions and already has incorporated
contributions from UCF.  The architecture is similar to what is currently
deployed at Harvard, but has all Harvard-specific parts of the code removed.

Native apps are in the works.

First-time configuration: From the top level, copy *
config/config.ini.template* to *config/config.ini*.  Point your server to
the */web* directory in the tree.  Consult the included documentation for
further customization instructions.

Device classification: Hits a separate service run by modolabs.

Main strengths:
- Template inheritance, which reduces code duplication between and within
modules
- Simple deployment, and can be configured and themed without knowledge of
PHP
- Ability to support multiple types of data sources in the same module
- Multiple contributors
- Supports local authentication

Main weaknesses:
- Newest of the three frameworks, thus subject to more change
- Fewer modules, although the Harvard implementation may provide some
reference and preview of upcoming modules
- Developers may find the logic verbose


On Thu, Jan 27, 2011 at 6:36 PM, Dave Olsen <dmolsen at gmail.com> wrote:

> Marco-
>
> With the very large caveat that I haven't played with the latest
> releases of MIT or Harvard I think these are the positives for the WVU
> fork... at least compared to the original MIT version:
>
> 1. documentation
>
> 2. more thought put into allowing configuration for third parties. v2
> still has its rough edges but v3 will definitely take a leap forward
> in that area.
>
> 3.  jQTouch + jQuery for richer, more native-like interaction
>
> 4. device detection is included in one package as opposed to two (at
> least for MIT. not sure about Harvard.)
>
> The cons are:
>
> 1. at least looking at the Harvard code base and assuming all goes as
> planned they'll have native apps to go along with the mobile web
> version. i don't plan on going that far as i'm only one guy.
>
> 2. jQTouch + jQuery are *heavy*. nice interaction but it comes with a
> price. also introduces some fun interaction issues.
>
> 3. no shuttles module by default.
>
> 4. v2 doesn't like MySQL. i personally think SQLite is more than
> enough for the project and it works well. in v3 MySQL, Postgres, and
> MSSQL support have been added via MDB2 support.
>
> If you're interested in the future direction of the WVU fork check out
> some of these blog posts related to it. They'll say v2.5 but I think
> I'm just going to move past that to v3 because I've had so many
> changes.
>
> http://www.dmolsen.com/mobile-in-higher-ed/?tag=mobile-web-osp
>
> The full list of recent changes and some things I still want to work
> on can be found in the projects CHANGELOG in the master branch on
> GitHub:
>
> https://github.com/dmolsen/MIT-Mobile-Web/blob/master/CHANGELOG
>
> If you need any further clarification feel free to let me know.
>
> On Thu, Jan 27, 2011 at 5:54 PM, Marco Rivadeneyra
> <marco.rivadeneyra at societao.com> wrote:
> > Hello, I'm new at this mailing list and interested in the solutions
> > presented by the iMobileU initiative for my school and would like your
> > opinion about the strengths and weaknesses of the 3 open source
> frameworks
> > (MIT, Hardvard and WVU) could you please help me?
> >
> >
> > --
> > Saludos,
> > Marco A. Rivadeneyra
> >
> > _______________________________________________
> > I-mobile-u mailing list
> > I-mobile-u at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/i-mobile-u
> >
> >
>
>
>
> --
>
> http://dmolsen.com
>
> _______________________________________________
> I-mobile-u mailing list
> I-mobile-u at mit.edu
> http://mailman.mit.edu/mailman/listinfo/i-mobile-u
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/i-mobile-u/attachments/20110131/9c213fec/attachment.htm