[Plugin] Plugin names

[shawninder]

In this issue, I'd like to decide what the names of all plugins will be and their respective priority.

We should be able to find each plugin at github.com/vigour-io/<name>

priority	name	other possible names	description & scope
1	status-bar	bars	native status bar control (and the menu bar on android)
1	env	environment, info, device, device-info, platform, client	provides static info about the device and platform's name and version, bundle id, etc.
1	network	connectivity	provides an observable for connectivity (wifi, 3G, 4G, none, etc.)
1	orientation		listens to the orientation of the device (pure js?)
1	pay	purchasing, money, payment, store, purchase	native purchasing and plugin architecture for web payments (pay pal, credit card, ...)
1	auth	login	login via facebook, google +, others
1	chromecast		Everything needed for Chromecast sender apps
1	share		Share via other apps (e-mail, facebook, twitter, google +, etc.).
1	infonline		InfOpen stuff
2	dial		everything DIAL
3	notify		native notifications
3	remote		Remote controls
4	fs		Native file system access including file transfer (upload/download)
4	settings	user-settings	Observable for device settings, e.g. preferred language, date & time format, etc.

For now, let's just agree on a name & priority for each plugin. The scope of each plugin is way bigger than what we need immediately, and prioritizing specific features will happen in that plugin's repo. For example, we won't care about the user's preferred date & time format for a very long time, but that plugin is indeed a # 1 priority because we will be interested in connectivity.

I'm not particularly attached to any of these names, so please propose alternatives for all of them. I'd like to have all these names settled by Sunday morning (no beating around the bush).

/cc @jimdebeer @youzi @gideonvd

[michielibiza]

• I would like to prepend "plugin-" to any name we choose (to keep more overview on git and on file system)
• I would make orientation part of env | info | device
• I (slightly) prefer these names:
  • plugin-purchase
  • plugin-device (for env)
  • plugin-share

[shawninder]

I think I agree with merging orientation with env. I also agree with renaming env to device I don't like prepending all the names with "plugin-" however. It should be transparent whether you're using a plugin or any other npm module.

@jimdebeer @youzi @gideonvd What do you guys think?

[youzi]

I like this latest draft

[jimdebeer]

no plugin -- maybe add something like "wrapper" (name of vigour native)

devices --> env

rest is a-ok if you ask me

[shawninder]

@jimdebeer What do you mean with devices --> env?

[michielibiza]

ok so what have we decided? what will be the repo name for the 'device' plugin? "vigour-oi/device" or "vigour-io/device-wrapper"?

[shawninder]

env: https://github.com/vigour-io/env

[michielibiza]

good, shall we close this issue then? is the list up to date with the latest insights? or will we still merge env with orientation, network and settings? It feels like me we shouldn't fragment our plugins too much as it increases build time and development time (keeping it all in sync and running more tests)

[shawninder]

I think the separation is useful. An app that doesn't use the internet doesn't need the network plugin, but it could need orientation. Also think of usage:

var statusBar = require('status-bar'); statusBar.display.val = 'hidden'

VS

var everything = require('everything'); everything.statusBar.display.val = 'hidden'

But you're right, the names are decided and so are the priorities. I even made the repos for the # 1 priority plugins. I just need to move vigour-native-statusBar to status-bar and then I will close this issue

[michielibiza]

I think developing 4 plugins that do almost the same will take a lot more time than developing one of them. Btw your use-case is easily fixed:

var statusBar = require('everything').statusBar; 
statusBar.display.val = 'hidden'

I'll just go ahead and build env with orientation and stuff included and if there is ever time left someone can split it into 4 repos.

[shawninder]

I disagree. We're going to start building 3 apps concurrently very soon. We want to use the final version of the API straight away and not have to go and change it later at 3 different places.

Although you can work around just about anything in javascript, combining the plugins forces you to load all of them (js and native code) even if you only intend to use one. Also, we would end up conflating the ready event for each of these functionalities, meaning we have to wait for all of them to be ready before being able to use any of them. Same thing for errors; it becomes unclear which part of the plugin is causing the error if we mash together many unrelated functionalities.

I believe that combining these plugins together rids them from the advantages of modularity. As for "making 3 plugins is longer than 1", it shouldn't be. The 3 plugins you refer to accomplish 3 different things. The part of the code that is common to all three can go elsewhere, either in vigour-native, or in plugin, which is a skeleton of a plugin holding what is common to all plugins. All plugins can pull from the skeleton to get the latest cross-plugin updates.

[shawninder]

To be clear, this skeleton thing is only for things that need to be repeated (like a cross-plugin explanation in the readme or cross-plugin npm scripts in package.json, things like that). Most of the cross-plugin stuff should be correctly modularized (and made accessible either as a standalone module or as part of vigour-native).

[michielibiza]

I just made a mistake that made me wonder about the plugin names... Wouldn't it be handy if the plugin's name does not clash with any existing npm package? I must have done something wrong and ended up with https://www.npmjs.com/package/status-bar in stead of our plugin...

So, if we want to ever release our plugins, they should probably all have a prefix to prevent name clashes. What do you think?

[shawninder]

The repo name doesn't have to be the same as the npm name, but yes we'll have to prefix for npm :( probably "vigour-"

[marcusbesjes]

@jimdebeer We discussed the following changes:

• create a facebook plugin with
  • facebook.share
  • facebook.login
• demote "share" plugin priority, no longer needed because of sharing directly through facebook app
• remove "auth" plugin: all login actions will have their place in their respective plugins (e.g. facebook.login or twitter.login)

You still want to go this route? Others agree?

[shawninder]

I don't like it.

Devices have this general share thing where you share stuff and they propose a list of all the share-capable apps on your device (whatsapp, slack, mail, hipchat, message, iCloud, twitter, save PDF to iBooks, snapchat, messenger, etc, etc, etc). So I don't see why the share feature sould be in the facebook plugin, as you may want to share with other apps, and we don't want one plugin per app (we'll never see the end of it).

Same goes for login. We currently only support logging in via facebook or e-mail, but it's reasonable to think we'll be logging in via oauth, twitter, etc, in the future. Do we really want one plugin per login-capable app?

Of course, my argument is less strong for login, as there is no general login via xyz dialog offered by native devices. But for sharing, this seems quite obvious to me.

[vidbina]

About the naming thing... I'd say let's use npm scopes. New NPM has already cost us quite a bit of extra effort so let's enjoy the perks at least. https://docs.npmjs.com/getting-started/scoped-packages

On Thursday, October 15, 2015, Shawn Inder notifications@github.com wrote:

The repo name doesn't have to be the same as the npm name, but yes we'llhave to prefix for npm :( probably "vigour-"

— Reply to this email directly or view it on GitHub https://github.com/vigour-io/vigour-native/issues/86#issuecomment-148381703 .

[michielibiza]

@ninjatux you asked for a rough estimate of the prio 1 plugins:

plugin	estimation	remark
status-bar	3h
env	1h
network connectivity	3h
orientation	2h
pay	8h	just play store, right? no native sdk for paypall I hope...
auth	8h	depends on how many varieties
chromecast	8h	never done this before, I don't know...
share	8h	also here it depends on what we need as a minimum
infonline	--	AFAIK not possible (see comment above)

[ninjatux]

@michielibiza don't forget facebook, it was included later but is needed for a specific implementation so we want to give it max priority

[shawninder]

8h for the pay plugin, you are so cute @michielibiza ! I guess you weren't there yet last time we did this, but there was a shitstorm of fuckness sourrounding this whole purchasing stuff: Incorrect documentation, broken test apis, blocked google accounts, lack of control over the actual store account, etc. Plus things have most probably changed considerably since then as well.. I hope you're right about this, but I would advise planning a little more time more this.

The other estimates make sense however :) Thanks

[michielibiza]

@shawninder haha, thanks for the feedback :) I think a lot here is about scope: 8 h for the pay plugin should be enough to get something working on a test account (since I already have something that worked beginning of the year, I think it shouldn't take too long to get that up and running). But indeed that doesn't include debugging play store setup in actual products! So I think we can gat a plugin that purchases from a test app in our own play store account. But indeed there is always some nightmarish version/key twiddling for products where we don't have access to the play store that can take days. This however should be part of the planning of the product itself.

Does that make more sense or do you still think 8h is too little?

[michielibiza]

@ninjatux So if we pull facebook out of the plugins auth and share what is left in auth and share (as a minimum requirement)? I think a facebook plugin should take about a day. But perhaps the estimates for auth and share would come down after that.

[michielibiza]

Oh and just to make one more thing clear: All my estimates are for the native side only. I'm assuming that the bridge stuff and the npm dependency shit is all taken care of. Do we need more ideas on how to limit breakage of dependencies given that none of the dependencies are done?

Furthermore I might need to do a tiny bit more on the android build process so in total it's about 7 to 8 days