Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

ship the current modules #224

Closed
michielbdejong opened this Issue · 21 comments

7 participants

@michielbdejong

i just saw that all the modules in https://github.com/RemoteStorage/remoteStorage.js/tree/master/src/modules are old. we should probably version the modules along with the library.

afaik we currently have the following modules, you can grep apps for 'defineModule' to find them:

  • root (in gh:nilclass/remotestorage-browser)
  • music (in gh:michielbdejong/music)
  • tasks (in gh:michielbdejong/todomvc)
  • documents (in gh:litewrite/litewrite)
  • tags (in gh:silverbucket/vidmarks)
  • videos (in gh:silverbucket/vidmarks)
  • money (in gh:xMartin/Gruppenkasse)
  • messages (in gh:michielbdejong/social)
  • code (in gh:michielbdejong/editor)
@michielbdejong

the 'money' one is actually still called 'gruppenkasse' in Grouptabs, but i think we should call it 'money' instead.

@jorin-vogel
Collaborator

Two questions:

  • Can someone explain to my why the modules are part of the core repo? Wouldn't it be more useful to have an own repo for each module?

  • Wouldn't it be useful to have a list of all modules (or schemas?) everyone can add stuff to? I'm thing of something like npm registry. What do you think?

@nilclass
Collaborator

+1, +1

how shall we name the repositories? "remoteStorage-{module}", "remotestorage-{module}", "remoteStorage.js-{module}"

the module registry could also be a repository ("remoteStorage-modules"?), including all modules as submodules.

@jorin-vogel
Collaborator

What do you think about the approach used by grunt.js? All grunt plugins are npm packages with the "grunt-plugin" keyword. We could use bower or npm. The keyword could be "remotestorage-module".

@michielbdejong

good idea to make separate repos.

i would call them as they are called in the DOM though, so remoteStorage.music, etcetera. with your permission i will start creating those repos tomorrow?

@skddc
Owner

What about separate JSON Schema files, btw? We can then have easy access to and interactive documentation for the data types, change type definitions without changing module code, accept new types without the need to create modules, etc...

(The way I see it, most modules don't need any type-specific methods, so defining the type should be enough. A lot of methods we have in there now should be public methods for all modules, or live in a general plugin, like "search" e.g.)

@michielbdejong

oh, is that stuff working yet? afaik none of the current modules were generated using the automatic module generation idea, they're all just defineModule() calls. example:
https://github.com/michielbdejong/html-music-player/blob/master/ext/js/music.js

@nilclass
Collaborator

@skddc #247 would be needed to support editing schemas without touching module code

@michielbdejong

see also remotestorage/remotestorage.io#23 (comment) about the naming,

@nilclass i think we should use a '.' not a '-', so for instance:

remoteStorage.music
remoteStorage.locations

because that's the names of the modules anyway. let's not introduce two ways to name each module, then we're back where we were with tab completion. :)

@jancborchardt
@skddc
Owner

In my opinion it should be remotestorage-modules/music. That way it's a) perfectly clear that all repos in that namespace are modules (which also makes the org repo list a maintenance-free module list), without the repo names being incredibly long and b) not polluting the core organization's repo list and notifications.

@jancborchardt

You mean a separate organization? That’s a bit much. How is that »polluting« the core organization’s repo list if it does belong to remotestorage proper? The notifications you can unwatch.

I agree with Michiel that remoteStorage.music is a good pattern for the repo naming, for reasons he stated.

@michielbdejong

i'm sorry guys, but between this, and people needing more time to think about name changes that were proposed two months ago, i've had a bit of a democracy overdose this week.

it's not rocket science, we just need a list of current modules in a place where people can find them; there are a million ways to organize and name that, and they are all valid.

the only option that is not valid is endless talk like we do now as a group, because nobody knows who else to look at for taking decisions. i feel the lack of management here is holding back progress. imho, @nilclass and @xMartin should make up their minds about who can take on that role.

i have created a 'modules' repo (just like owncloud has a 'core', and an 'apps' repo). for now, it's on my own github user so as not to step on anybody's toes. When management is ready for it, you can fork it into the org from https://github.com/michielbdejong/modules

Let's just get shit done.

gangnamtocat

@jancborchardt
@michielbdejong

yes, transfer ownership yeah.

yes, and afaik, @nilclass already appointed @xMartin for this but we still seem to be a bit in limbo.

@silverbucket
Owner
@nilclass
Collaborator

+1

Good. So let's use remoteStorage.modulename. I have renamed remoteStorage.locations accordingly.

@michielbdejong Regarding the "modules" repository, could you change that to use submodules instead, as soon as all modules have their own repo?

If nobody knows any reason not to, I will start creating module repositories in ~2 hours (using the module files from michielbdejong/modules).

@silverbucket
Owner
@skddc
Owner

Seriously, you're still using uppercase in repo names and URIs now. I'm not endlessly discussing, I'm telling you that that is a bad idea for the 4th time now.

It might be a bit frustrating to have a longer discussion about these things, but as you see the fast decisions you took before that were bad and ended in chaos. Everybody is invited to lean back and wait for the others to talk it out. You don't have to vote on something every day, only intervene when you disagree completely. That way, everybody can watch out for bad decisions, and whatever the unimportant good ones are or how long they take, doesn't matter.

@ahdinosaur

i really like the idea of decentralizing modules by having each module be a separate repo, under the ownership of whoever writes / maintains it, especially if installing a new module is as simple as npm. +1

@michielbdejong

thanks for the feedback! right now, as you can see in https://github.com/remotestorage/modules we don't have many modules and they're all very small still. so far, all modules were written by people who have commit access to that repo, so i don't think this is really a problem.

if in the future people run into practical difficulties, they can set up more advanced systems. for now i think it's good enough - at least we have a go-to place now for seeing what modules exist and what their latest version is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.