You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several possible strategies are listed below.
1. Accept that the Java implementation different from Perl.
1.a. Continue desktop development without being concerned about the fact that
Perl is implemented differently.
1.b. Refactor existing Java classes so that non-GUI code can be reused for
Android.
2. Incrementally harmonize the Java and Perl APIs.
2.a. In Java, move GUI code out of API classes, and vice versa.
2.b. Then start work on making the Java and Perl APIs more similar.
2.c. After the new Java API is complete, and is being used in the desktop
application, then look at using it for Android.
3. Start with a clean slate, but continue processing data on the local machine:
3.a. Enhance the existing Java application until current goals are met.
3.b. Switch focus to version 2.0, where we would:
3.b.1. Implement a new Java API first, reusing existing code wherever possible.
3.b.2. Write new desktop and/or Android GUIs that use the the new API.
4. Start with a clean slate, but switch to server-side data processing:
4.a. Enhance the existing Java application until current goals are met.
4.b. Switch focus to version 2.0, where we would:
4.b.1. Provide web services written in Perl, based on current Perl code.
4.b.2. Write new desktop and/or Android GUIs that consume the web services.
4.b.3. Allow the user to download pre-processed data for offline use.
4.b.4. Allow the user to restrict downloads by language and date range.
5. Start with a clean slate, but move away from real-time data processing.
4.a. Enhance the existing Java application until current goals are met.
4.b. Switch focus to version 2.0, where we would:
4.b.1. Use existing Perl code to generate static HTML. Regenerate the HTML as
needed when source data changes.
4.b.2. Write new desktop and/or Android GUIs that download static HTML for
offline use (possibly using a built-in Subversion client).
4.b.3. Allow the user to restrict downloads by language and date range.
Other thoughts?
If you need free web hosting to tinker with any of the above ideas, have a look
at RedHat's free platform-as-a-service solution (openshift.com).
Original issue reported on code.google.com by ps008v...@gmail.com on 6 Feb 2015 at 6:32
The text was updated successfully, but these errors were encountered:
Original issue reported on code.google.com by
ps008v...@gmail.com
on 6 Feb 2015 at 6:32The text was updated successfully, but these errors were encountered: