{"action":"created","issue":{"url":"https://api.github.com/repos/readium/readium-2/issues/20","repository_url":"https://api.github.com/repos/readium/readium-2","labels_url":"https://api.github.com/repos/readium/readium-2/issues/20/labels{/name}","comments_url":"https://api.github.com/repos/readium/readium-2/issues/20/comments","events_url":"https://api.github.com/repos/readium/readium-2/issues/20/events","html_url":"https://github.com/readium/readium-2/issues/20","id":188360641,"number":20,"title":"Using an agile approach to design and prototype the architecture for Readium-2","user":{"login":"rkwright","id":3025864,"avatar_url":"https://avatars.githubusercontent.com/u/3025864?v=3","gravatar_id":"","url":"https://api.github.com/users/rkwright","html_url":"https://github.com/rkwright","followers_url":"https://api.github.com/users/rkwright/followers","following_url":"https://api.github.com/users/rkwright/following{/other_user}","gists_url":"https://api.github.com/users/rkwright/gists{/gist_id}","starred_url":"https://api.github.com/users/rkwright/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/rkwright/subscriptions","organizations_url":"https://api.github.com/users/rkwright/orgs","repos_url":"https://api.github.com/users/rkwright/repos","events_url":"https://api.github.com/users/rkwright/events{/privacy}","received_events_url":"https://api.github.com/users/rkwright/received_events","type":"User","site_admin":false},"labels":[{"id":446988857,"url":"https://api.github.com/repos/readium/readium-2/labels/func:Planning","name":"func:Planning","color":"b6d7a8","default":false},{"id":446985665,"url":"https://api.github.com/repos/readium/readium-2/labels/priority:Blocking","name":"priority:Blocking","color":"ff0000","default":false},{"id":446986003,"url":"https://api.github.com/repos/readium/readium-2/labels/status:WIP","name":"status:WIP","color":"cfe2f3","default":false},{"id":446985752,"url":"https://api.github.com/repos/readium/readium-2/labels/type:Discussion","name":"type:Discussion","color":"d9d2e9","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-11-09T21:46:26Z","updated_at":"2016-11-10T11:46:22Z","closed_at":null,"body":"In the Readium-2 engineering meeting on 9 November, the team discussed two big issues:\r\n\r\n- how to get to an actual architectural design for Readium-2\r\n- what approach should be used to get there\r\n\r\nPreviously, the contributors had agreed (at the behest of the Readium board) to generate three deliverables in Phase 1 of the Readum 2 project \r\n\r\n- A design for the the architecture of Radium-2\r\n- A set of interfaces that app-developers could design to\r\n- An estimate of the scope/manpower/timeframes for reaching a viable Readium-2\r\n\r\n where Phase 1 was to be completed in the November/December 2016 timeframe.  As part of that process, the group reached a consensus that\r\n\r\n- Readium-2 would focus on the mobile solution strategy, i.e. iOS and Android and leave JavaScript-based solutions like the Chrome Extension and the Cloud Reader for later\r\n- that development on those platforms would be largely (if not completely) per-platform, i.e. the implementation would be based on native tools and code\r\n\r\nHowever, one of the implications of this approach was that R2 would effectively be a complete rewrite of the existing codebase.  Several members of the group were uncomfortable with this approach (see email thread here).\r\n\r\nIn the discussion on 9 November, however, the group came to the conclusion that trying to develop the code in an incremental fashion by developing pieces of Readium-2 separately then integrating them into a fork of Radium-1 was most likely an unworkable solution.  The ripple of effect of changing  APIs and the behavior of code modules would make that very difficult.\r\n\r\nThe group came to the conclusion that a more viable solution would be\r\nTo start with the most fundamental piece of an EPUB reading system, the parser\r\n\r\n- Write the interface(s) for the parser using TypeScript (for the typing ability)\r\n- Prototype this interface and design in TypeScript\r\n- Develop tests along with this code to ensure that it all works as designed\r\n\r\nWhen the parser would be complete, move onto the next step (e.g. the model representing the parsed EPUB) and so on.  Eventually, the completed and tested code would/could be “ported” to native languages and libraries for iOS and Android.  The TypeScript (transpiled to JavaScript) could be used as a replacement for the ReadiumJS stack as well.\r\n\r\nArguably, this represents a move from the original “waterfall-like” design/implementation approach to a more agile approach.  \r\n\r\nPros:\r\nThis allows the development to be done bottom-up in a more natural design process\r\nThere is little or no integration pain since the development is bottom up\r\nThe resulting code is cleanly developed (with typing) and associated tests\r\nCons:\r\nThe time from beginning to the process will very likely be much longer to reach native-code implementation since the TypeScript version must be developed first\r\nSince the development would be agile, providing a scope and timeframe is infeasible, as is concrete interfaces win a specified timeframe\r\n?\r\n"},"comment":{"url":"https://api.github.com/repos/readium/readium-2/issues/comments/259670354","html_url":"https://github.com/readium/readium-2/issues/20#issuecomment-259670354","issue_url":"https://api.github.com/repos/readium/readium-2/issues/20","id":259670354,"user":{"login":"llemeurfr","id":14943186,"avatar_url":"https://avatars.githubusercontent.com/u/14943186?v=3","gravatar_id":"","url":"https://api.github.com/users/llemeurfr","html_url":"https://github.com/llemeurfr","followers_url":"https://api.github.com/users/llemeurfr/followers","following_url":"https://api.github.com/users/llemeurfr/following{/other_user}","gists_url":"https://api.github.com/users/llemeurfr/gists{/gist_id}","starred_url":"https://api.github.com/users/llemeurfr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/llemeurfr/subscriptions","organizations_url":"https://api.github.com/users/llemeurfr/orgs","repos_url":"https://api.github.com/users/llemeurfr/repos","events_url":"https://api.github.com/users/llemeurfr/events{/privacy}","received_events_url":"https://api.github.com/users/llemeurfr/received_events","type":"User","site_admin":false},"created_at":"2016-11-10T11:46:22Z","updated_at":"2016-11-10T11:46:22Z","body":"Using Typescript for modeling the Parser interface has three concret advantages\r\n- it is an alternative to the large set of IDL languages that nobody will agree about\r\n- it is a way to test Typescript, which is viewed by the group as an interesting solution for the JS part.\r\n- it is a way to avoid having to choose btw Java, Objective -C and Swift  for such a reference development. Some in the groupe have XCode, others have Android studio, everybody can manipulate JS code. \r\n\r\nBut as soon as we have agreed on the interface definition, it will be good to have iOS/Android implementations of this parser. \r\n\r\nI note one issue with a JS parser = the streaming unzip issue. How can we solve it? via node-js with embedded C code?\r\n\r\n"}}
{"actor":{"display_login":"llemeurfr"}}