CabThrottle uses the new Event Bus design I made up in 2014.

Pros and cons:

• Pro: The event bus implementation is simple and minimalist.
• Pro: There is no annotation processor to find subscribers, so no complicated build setup.
• Cons: It suffers from the typical good/bad part of a disconnected sub-system. The whole point is to remove hard dependencies, but the side effect is that it hides the dependencies. They are still there, just not so visible.
• Pro: The "user" dependencies are simple enough to find. Search for code using any of the bus constants to find the users. Done.
• Cons: The bus messages rely on a numeric ID and the simple naive approach used is to create "namespaces", a.k.a. ID ranges. E.g. 1000 is the base for the Discovery bus messages. But it doesn't say what is the max, and there's no centralized place to look at all the usage ranges (on purpose, because decentralized). That means it's hard to place it in a library and be sure there won't be conflicts down the road with something else.
• Cons: There's some inefficiency in sending messages to subscribers without knowing if they want to listen to them. The receivers can subscribe to message class types, but that's not too useful when for example sending a string notification.

So really the weakness is the ID range issue. Ideally each message would use an enum but the Java implementation of enums kind of sucks -- can't make a "generic" enum, and they are too heavy for serialized number sequences. Another alternative is to use a hash code as a base (e.g. NSD DiscoveryMixin.class.getHashCode() but even that is not guaranteed to not have collisions and it would prevent from making static final int IDs.

It does bring back some potential for dagger.

In usage, I mostly use the event bus for notification, obviously. E.g. NSD discovery mixing sends bus messages when a new host appears or vanishes. Well I can just register a listener and be done with it, since that's essentially what the event bus does. One point of the event bus is that the subscriber could be a view or something that does not have access to the sender object because it would require passing everything via globals or something, as I used to do before. Well that particular problem is well solved by dagger. E.g. there would be a module for the discovery client and whatever code need to use it, be it the activity to start the client or the UI to display its state, can simply access it via injection, then subscribe a listener as needed.

Same goes for throttles for example.

The other realization is that this seems to also fit the Reactive pattern of having observable streams. Each bus is essentially a stream, and users can get the stream via dagger.

Worth looking into it.

It still feels like shoe-horning to use dagger in my apps (e.g. CabThrottle).

Reactive … Potentially interesting or totally hyped:

• http://reactivex.io/ and https://github.com/ReactiveX/RxJava -- an observer pattern (the "reverse" of a subscriber pattern) to do async operations.
• It has stuff for Android (https://github.com/ReactiveX/RxAndroid).
• Potential: for tasks that involve multiple AsyncTasks (e.g. google play login) or for replacing my event bus. (huh, not really?)

Unrelated:

• Dokan, a user-mode file system for Windows. https://dokan-dev.github.io/ 

Proposal doc as been sent:

• Option A: use the cheaper Intel “Ubuntu” stick. Fairly good price at $39. Use it as a dumb remote and just display a web page served by the JMRI server.
• Option B: use the beefier Intel Windows 10 stick. $125 or such. Run a C# or Java app that displays an SVG map and communicates with JMRI via the JSON server or the WiThrottle server.

Should look into option A, software side:

• Server side, a dedicated HTTP server. Could be either IIS or a custom Java servlet. The latter is probably easier to deal with, on a custom non-80 port.
• Explore what the JSON server in JMRI can and cannot do. Eg it can serve states, but does it allow performing changes? ⇒ yes, e.g. JMRI\java\src\jmri\server\json\turnout\JsonTurnoutHttpService.java doPut().
• Another option is to do a Java/Jython bridge like used with Conductor. This makes it trivial to start/shutdown at the same time as JMRI and can use the Jython interface to access turnouts.
• On the client side, we just need to display some SVG or bitmaps. Multiple maps can be trivially handled by having different query parameters.

Server side:

• Jetty / JSP
• Restlet
• Swing for UI
• JMRI Jython script dynamically linked to a Java JAR

Client side:

• jQuery
• SVG
• vanilla JS

Part of the project goal was to explore Firebase. From what I see right now:

• Firebase auth looks bolted on. I understand the main point is having different login systems (google, email, etc.) and the Firebase server generates a unique user id for new users, trying to regroup them across login system (e.g. email vs google account.)
• The pro is having a single user id regardless of the authentication method.
• The obvious cons is the secondary server authentication lookup to convert the googler user id into a firebase user id.
• Pros: not having to implement it using my own app engine instance + db.
• The "realtime" database seems to work as promised. However:
• User compartmentalization is done at the app level and by server-side rules. It seems fragile in the sense that a programming error or a design flaw could possibly expose all data to all users.
• All user data is visible as-is in the console, with a limit of 500 users or similar. Search can be done by user id. That seems like a potential PII issue and at the same time not sure how much it can really scale. What happens with 1 million users?
• How much "realtime" is the database? I wasn't even able to sign-in on a low cell phone connection (vacation).
• Pros: not having to implement it using my own app engine instance + db.
• I did not try "remote app settings". That seems like a generalization of the realtime db readable by all apps. Maybe that's the point and just enough.
• I implemented the firebase analytics but I can't see the results yet, the console is quite unresponsive over a low cell connection.
• I don't see anything obvious that is an advantage over pulling google analytics, except it's one less library and in theory it's tied to firebase user ids.

Overall I'll have to defer to see how this behaves with a better connection.

I do have my concern with the speed of the firebase requests.

The other thing not so clear is how does that scale.

Overall I guess the point of Firebase is having to avoid implementing an extra app-engine backend server. If it were used in an application that requires such a service, then the point seems rather moot.

For example I started a project with the idea of having both Firebase and App Engine. I thought I needed app engine for the storage of users ACLs, themes, and live instances but I see these could be replicated in the Firebase realtime db using denormalized storage & rules. The other reason I wanted app engine was to have all the processing on the server and the web site to be merely a "dump" presenter (using the MVP distributed pattern) .

Using Firebase, it makes more sense to have all the logic client side, with only storage on the server side.

⇒ It turned out to be disappointing. One issue is the login time on the Android app. It takes several seconds (10-20 s?) for the app to authenticate via google auth then via firebase before it can do any queries.

What I have at home is an RPi monitoring some status. The interesting properties of Firebase in this case are receiving notifications (aka GCM) and the use of the distributed "realtime" database. The question is how do the events get generated. Can a script running on the RPi send data to Firebase?

• "Firebase Notifications" are sent solely using the Firebase console web UI. Not adequate.
• "Firebase Messages" can be generated via an HTTP POST with an OAuth token; however this requires getting the registration tokens for each device that should receive, which doesn't seem practical.
• "Firebase Database" is a synchronized JSON store. There are many REST wrappers (Go, Python, or just curl) that seem appropriate for the RPi to generate data. Authentication rules are set in the database console. See https://firebase.google.com/docs/database/rest/start 

Interesting: Material Design Lite. https://getmdl.io/

Application could be interesting on the Trains pages. Find a way to inject in the gdoc-generated pages. [done]

Looking at the firebase tutorials for web / android…

Web:

• Uses nodes.js / npm for local testing + deployment.
• Google Cloud Whatever project with console for management.
• Firebase console seems to mostly cover deployment & database/files for web, not messaging or analytics. GA can be added separately anyway.
• Pros: authentication with a variety of platforms (G, Tw, FB, email).
• Overall interesting.

Android:

• Seems more refined with a variety of services: database, email app invite, GCM notifications, remote config values, analytics / crash reporting. And of course multiple auth providers. Also as admob support.
• Seems like a good value: reduce boilerplate for a bunch of things (auth, crash, ga, db, remote config.)
• Nothing about IAB, to be done separately.

From the Firebase tutorial, a good javascript ide is https://atom.io

• open source, free, runs js.
• using http://electron.atom.io to build "cross platforms apps using html+js"

Javascript not-quite-replacements:

• CoffeeScript: http://coffeescript.org … compiles 1-to-1 to vanilla JS.
• TypeScript: https://www.typescriptlang.org … also a compiler. More JS like, with decoration for types and access.
• - ES6: ...
• The high level summary is that CoffeeScript is Ruby/Python like and TypeScript is .Net like in their sugar-syntax addition/replacement.
• TypeScript seems to have a VS.Net add-on (confirm?)
• In terms of age: CoffeeScript < TypeScript < ES6.

Point of view: CoffeeScript is different enough that it's a new habit to learn. TypeScript is JS plus some sugar so can be used to decorate existing JS stuff. ES6 is the way to go but what about support? Compatibility chart here: ES6 supported in V8 since Chrome 42 (so also in Node.js). Mostly there in recent Firefox and MS Edge.

Bottom line: don't bother with CS/TS. Go with ES6 where possible.

One more thing to give a try: Firebase.  firebase.google.com.
What does it do, or doesn't? Why would I care?

It's apparently based on top of the google cloud platform. Key features include analytics, database, storage, hosting, authentication, and cloud messaging.

Idea would be to use the central monitoring and the AP projects to test it.

• Authentication: SDK has drop-in UI for auth, with several providers (G, FB, Twitter, email).
• "Realtime Database" is actually connected clients with a network-synchronized offline-persistent db. This is similar to one of my homebrew projects (except it's already done.)
• "Remote Config" seems very similar, but with values that can be fetched yet not activated.
• "Storage" is to be able to upload user-generated content. Files are accessible via the Google Cloud Platform SDK too e.g. for server-side operations.
• "Notifications" seems to be all about manually sending messages to users.

⇒ Try the web tutorial.

https://www.polymer-project.org/0.5/
Version 0.5 with core-scaffold (generic web site template), core-toolbar.

https://www.polymer-project.org/1.0/ 
With material design elements.

"Look at https://github.com/PolymerElements/app-layout-templates for a few simple scaffolds.

You should be able to copy one of those templates to replace core-scaffold in your application.

If you want a more comprehensive starting point for an app, you can also look at https://github.com/PolymerElements/polymer-starter-kit"

Example in use: http://google.github.io/dagger/ 
Code behind it: https://github.com/google/dagger/tree/gh-pages 

Also interesting: Material Design Lite. https://getmdl.io/