Received: from mx2.mailbox.org (mx2.mailbox.org [80.241.60.215]) by mail-b.sr.ht (Postfix) with ESMTPS id 1B48AFF0AA for <~qaul/community@lists.sr.ht>; Tue, 30 Jun 2020 23:00:43 +0000 (UTC) Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id DD5C8A2FC8 for <~qaul/community@lists.sr.ht>; Wed, 1 Jul 2020 01:00:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter03.heinlein-hosting.de (spamfilter03.heinlein-hosting.de [80.241.56.117]) (amavisd-new, port 10030) with ESMTP id u-JVIwcPEwu7 for <~qaul/community@lists.sr.ht>; Wed, 1 Jul 2020 01:00:38 +0200 (CEST) From: Katharina Fey To: ~qaul/community@lists.sr.ht Subject: Worklog/ update W27: alpha milestone Date: Wed, 01 Jul 2020 01:00:34 +0200 Message-ID: <87sgecxip9.fsf@kookie.space> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-MBO-SPAM-Probability: 0 X-Rspamd-Score: -5.79 / 15.00 / 15.00 X-Rspamd-Queue-Id: BBF6D1753 X-Rspamd-UID: ab65c4 --=-=-= Content-Type: text/plain Hello qaul.net community mailing list, I just pushed some changes to the main branch (develop) that implement most of the android glue code to make the app actually work (the wifi-direct connection mode is partially implemented and needs some channel magic in kotlin to work). There's some caveats though, only the chat service is exposed, and after user creation it's currently not possible to change your name. Expect bugs! If you find anything that blocks you from continuing, please e-mail me (Cc to kookie@spacekookie.de), and I'll have a look before the 13th of july. AFTER the 13th of July I'll be off the grid for 2 weeks!) Hope testing goes as smoothly as possible and yields some useful data about the existing code! ~k --- I'm writing this e-mail while still hacking to keep track of a few things that are really not solved well, or just need to be solved at all as the testing progresses. Consider this a TODO list for the next few months. - Find better Java - Rust FFI abstraction The JNI crate is quite cool and good, and makes a lot of the JNI stuff possible, but it's not great, and we need a more high level abstraction over it. Especially conversions from Rust to Java types could potentially be automated, if we give a Rust crate access to the java module, parse the java code and output trait implementations for `ToJObject`, `FromJObject`, etc. The main idea would be to have a way to generated both the function stubs, code that saves and retrieves data from the passed in `this` instance, the JNIEnv, and also handles the memory domain of the native state (currently this is being done by manually calling std::mem::forget). We should have a look if there's more type system magic that I'm missing so that we can make sure we never accidentally clean up our work state. - Subscription types Currently the only way to get data into the Android app is by loading a view and having it fetch data. A much better approach would be to create a generic interface that can be pushed to, which then handles updating views, and then hooking up the push code from the Rust subscription objects. - Hook up filesharing, voice, and feed services to android views - Try to deduplicate recycler view adapter code (especially with subscriptions in mind) - Fix the issue where the registry screen isn't full screen - Make text fields always focus by the keyboard - The chat view should fill out the whole screen, not just the inner frame inside the nav view holder - Populate avatars from local and remote users - Figure out alexandria persistence on Android - Create a connection management dialog - Additional menus? - Is the bottom nav enough, plus an overflow ... menu? - Do we need a sidebar that has more items? - How to communicate the general app-state (not just notifications, but connections? - Unify API endpoint language - All functions of the same type (create, update, ...) should behave the same across the whole library ecosystem - Singularise/Pluralise consistently - Name fields in types consistently - Investigate new async_std channels API update - Start laying out the basics for the service-service RPC server - Look into specifications for the ratman transport encoding (see existing standards) - Test timestamp behaviour between services (currently only chat has working timestamps) - Figure out a second endpoint API to make the remove_ep API on the router redundant: we could communicate additional metadata for endpoints that support it, such as deleting or configuring it after the router has already started running. - Pick a serialisation format and stick with it (bincode all the way?) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEVV8uS2+H+RpBEGaekHNKnmGcimwFAl77xBIACgkQkHNKnmGc imyimw/+O4hn5epePaWSEiWTZUwib2uRyWzxAeOtBYk0XmW7NfFBRxKLTxDH9gNg S2GK/OqRdM8cxR+FVzzBLPD/JyTTECeNiBeUHCCTvKrvFJlXfD+Ehw5Fbn0iZNXX oBso21gxOlRwNbfIykvxCcFHTD1sYLEuKGiqounxrcLRJMebgVZ/zIUo1LSdHL0c 1rQi0Jo8liBjEYsMzvHifzdRFXsV0f1DQzOWKdMxW1Yt17goRd/aGhbWumR7bAU2 W731vrYay+l56mGedBY3SBWj2nTc3OOKpiMcykyCMm+U8odQIyIh2zPKvab9X3Xe FhTg6knEvOT8mEdlS4ZAxhWuxux+AwQ4CgigsZBLetUt1IJBvtxEa2oCcABvnvjG 4xr+Tw9i5hlQVEi+qG8wAhwc3ajq60BWR2Gfndf02T5RKJ07+dTeIBF6yN6TkGk6 ELUjlc2yh6G4lsRFBjGngvURTd9cAiTJ+iyjNZ4zpqwNvvpTkKQCnBomMXM+AoHA XrNC6DXIGkU861rTHe4Op7PhcXjr/UKnnc7mZpvCZ7ZRGkRMN3WnYcMf3A5AMQ9S 5Q5FyDrhO7e2NwJfXuS3ltdaabRPWfmVIv4KqU/f0HHL3qcegwptqWpp+n/Ilst2 LTJsSWqSdhvRHeoytfsFIhYueqz3qEiGlmBnvJZwTOCVm7zM/l8= =Dp0q -----END PGP SIGNATURE----- --=-=-=--