Marco and others,<br><br>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<br>
decide which framework to choose.<div><br><div class="im"><p>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.</p>
<p>If you are making a choice among the three frameworks, here are some points by which you can compare.</p>
<p><b>Mobile Web OSP</b></p>
<p>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.</p>
<p>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.</p>
<p>First-time configuration: At the top level of the tree, copy the file <i>config.gen.copy.inc.php</i> to <i>config.gen.inc.php</i>. Edit the defintions as necessary. Point your server to the <i>/web</i> directory in the tree.</p>
<p>Device classification: Built into the code that generates web content; no separate server required.</p>
<p>Main strengths:<br>
- Wide deployment<br>
- Openly developed for the longest time<br>
- More documentation<br>
- Incorporation of jQTouch (and eventually jQuery Mobile, which is still pre-beta) for the Webkit interface.</p>
<p>Main weaknesses:<br>
- Less suitable for use with non-mobile-web interfaces</p>
<p><b>MIT Mobile</b></p>
<p>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.</p>
<p>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.</p>
<p>First-time configuration: Three files need to be edited in the top-level directory <i>/mobi-config</i>. These are <i>mobi_web_constants.php</i>, <i>mobi_lib_constants.php</i>, and <i>mobi_lib_config.php</i>. Be careful to look at all constants, especially those pointing to a location on the local machine. Point your server to the <i>/mobi-web</i> directory in the tree.</p>
<p>Device classification: Hits a separate service running the supplied device classification code.</p>
<p>Main strengths:<br>
- Open source native apps<br>
- Maintained by the people who did the original MIT Mobile project<br>
- Arguably the most feature-rich of the frameworks, and feature set grows fast. Great place to look for ideas.</p>
<p>Main weaknesses:<br>
- A lot of functionality is MIT-specific<br>
- More complex configuration and deployment</p>
<p><b>Kurogo Mobile Web</b></p>
</div></div><p>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.</p>
<p>Native apps are in the works.</p>
<p>First-time configuration: From the top level, copy <i>config/config.ini.template</i> to <i>config/config.ini</i>. Point your server to the <i>/web</i> directory in the tree. Consult the included documentation for further customization instructions.</p>
<p>Device classification: Hits a separate service run by modolabs.</p>
<p>Main strengths:<br>
- Template inheritance, which reduces code duplication between and within modules<br>
- Simple deployment, and can be configured and themed without knowledge of PHP<br>
- Ability to support multiple types of data sources in the same module<br>
- Multiple contributors<br>
- Supports local authentication<br></p>
<p>Main weaknesses:<br>
- Newest of the three frameworks, thus subject to more change<br>
- Fewer modules, although the Harvard implementation may provide some reference and preview of upcoming modules<br>
- Developers may find the logic verbose</p><br><br><div class="gmail_quote">On Thu, Jan 27, 2011 at 6:36 PM, Dave Olsen <span dir="ltr"><<a href="mailto:dmolsen@gmail.com">dmolsen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Marco-<br>
<br>
With the very large caveat that I haven't played with the latest<br>
releases of MIT or Harvard I think these are the positives for the WVU<br>
fork... at least compared to the original MIT version:<br>
<br>
1. documentation<br>
<br>
2. more thought put into allowing configuration for third parties. v2<br>
still has its rough edges but v3 will definitely take a leap forward<br>
in that area.<br>
<br>
3. jQTouch + jQuery for richer, more native-like interaction<br>
<br>
4. device detection is included in one package as opposed to two (at<br>
least for MIT. not sure about Harvard.)<br>
<br>
The cons are:<br>
<br>
1. at least looking at the Harvard code base and assuming all goes as<br>
planned they'll have native apps to go along with the mobile web<br>
version. i don't plan on going that far as i'm only one guy.<br>
<br>
2. jQTouch + jQuery are *heavy*. nice interaction but it comes with a<br>
price. also introduces some fun interaction issues.<br>
<br>
3. no shuttles module by default.<br>
<br>
4. v2 doesn't like MySQL. i personally think SQLite is more than<br>
enough for the project and it works well. in v3 MySQL, Postgres, and<br>
MSSQL support have been added via MDB2 support.<br>
<br>
If you're interested in the future direction of the WVU fork check out<br>
some of these blog posts related to it. They'll say v2.5 but I think<br>
I'm just going to move past that to v3 because I've had so many<br>
changes.<br>
<br>
<a href="http://www.dmolsen.com/mobile-in-higher-ed/?tag=mobile-web-osp" target="_blank">http://www.dmolsen.com/mobile-in-higher-ed/?tag=mobile-web-osp</a><br>
<br>
The full list of recent changes and some things I still want to work<br>
on can be found in the projects CHANGELOG in the master branch on<br>
GitHub:<br>
<br>
<a href="https://github.com/dmolsen/MIT-Mobile-Web/blob/master/CHANGELOG" target="_blank">https://github.com/dmolsen/MIT-Mobile-Web/blob/master/CHANGELOG</a><br>
<br>
If you need any further clarification feel free to let me know.<br>
<div><div></div><div class="h5"><br>
On Thu, Jan 27, 2011 at 5:54 PM, Marco Rivadeneyra<br>
<<a href="mailto:marco.rivadeneyra@societao.com">marco.rivadeneyra@societao.com</a>> wrote:<br>
> Hello, I'm new at this mailing list and interested in the solutions<br>
> presented by the iMobileU initiative for my school and would like your<br>
> opinion about the strengths and weaknesses of the 3 open source frameworks<br>
> (MIT, Hardvard and WVU) could you please help me?<br>
><br>
><br>
> --<br>
> Saludos,<br>
> Marco A. Rivadeneyra<br>
><br>
</div></div>> _______________________________________________<br>
> I-mobile-u mailing list<br>
> <a href="mailto:I-mobile-u@mit.edu">I-mobile-u@mit.edu</a><br>
> <a href="http://mailman.mit.edu/mailman/listinfo/i-mobile-u" target="_blank">http://mailman.mit.edu/mailman/listinfo/i-mobile-u</a><br>
><br>
><br>
<font color="#888888"><br>
<br>
<br>
--<br>
<br>
<a href="http://dmolsen.com" target="_blank">http://dmolsen.com</a><br>
<br>
_______________________________________________<br>
I-mobile-u mailing list<br>
<a href="mailto:I-mobile-u@mit.edu">I-mobile-u@mit.edu</a><br>
<a href="http://mailman.mit.edu/mailman/listinfo/i-mobile-u" target="_blank">http://mailman.mit.edu/mailman/listinfo/i-mobile-u</a><br>
</font></blockquote></div><br>