Jingo as a module

[strawhatgami]

Hi,

I'm continue adapting Jingo to my app, this time I made jingo pluggable to an express app as a module. More infos on the example app file.

[claudioc]

Hi,

why don't you publish your own fork of Jingo? I think that would be the better way, don't you think?

Great job, so far :)

[strawhatgami]

I thought of making my own app before (and when) searching a wiki that - even partially - suit my needs.

I finally choose to improve an existing wiki with the functionalites I need instead of developing my own, because:

• I already developed some Nodejs modules for my app from scratch, one was quick to do, the other (that is - a bit - less complex than a wiki) was a pain because it takes me too much time to develop (by the way I haven't yet a final version of it). I am a junior developer that wants to experience the world of developing, and develop a module from an existing code actively maintained looks like an experience I haven't.
• I want if possible that the code I can develop can serve other people while there is no bad side effect for me
• use an open source public module actively maintained by several people is more likely for me to guarantee security than developing my own module

Nevertheless, I will delete my Jingo fork on Github when I will have finished my improvements on it: I don't want to have a fork on Github, because:

• I don't want to maintain an open source piece of code for now, I have no time for it. Why not in some month/years?
• Even if the fork is one of the strongest force of the world of free software, it's also a huge weakness: it divides the efforts made by collaborators to maintain a software by 2 (or more), without taking in account the same mechanism on the success of the initial software. I don't want to publish a fork either with no success (so finally something just for me, that don't need to be on Github) or that will decrease the success of another module (that need it, as every open source piece of code)?
• I don't want to publish on my name (mainly or only) a module I will use in my app publicly for security reasons: my app will have as users people with a certain IT culture, with a substantial part of script kiddies that I can reasonably envisage will try to put my main app down. If I can make their job harder just by don't show too easily what I developed, it's OK for me (I know there will be traces of my contributions, but it's better than nothing).
• Publish on an actively maintained repo allowed me to have code reviews, and to get advice on how to improve the quality of my code.

Maybe what I've done is not in what you planned for Jingo, and from my point of view there is no problem: if there is something I can correct in my PR then just say me, else I will just keep that piece of code for me.

I will develop a last functionality for Jingo I suppose I will make as a PR in a few weeks/months: a namespace (or tree, I haven't decided yet) support. Does such a PR interests you? If it doesn't, I'll just make the functionality only for my app: I'll spare the time to make a code that respects Jingo's conventions and it will also be better for the security reason I mentioned above.

[claudioc]

@strawhatgami I understand perfectly your points, because I have been considering a lot of them while developing (and publishing) some – if not all – my packages.

Honestly, I don't have the time and the energies (I am also following other projects, at the moment – some of them not published yet) to understand all the ramifications your design decisions would make for Jingo as it is now and – more importantly – what may happen to the existing installations. Every time I change a configuration option, the time spent to figure out all the possible implications is more that the time spent coding that single feature. Figuring out a deep rewrite like this one it's a bit too much (what could go wrong, how and if there would be a "compatible mode", how to setup the defaults, how to have people "migrate"...).

This is why I asked you to go ahead and fork: not because I do not appreciate your work or because I don't want to merge the PR! My opinion is, very simply, that a fork would be the best option for both of us. You'll be free to work on any feature your new design will bring to jingo and I can concentrate on maybe another big change I have in mind for Jingo [1] without shaking the ground too many times (for the end users). If you don't want to create a public fork, I understand you. But at the same time, please don't think that I just "don't want you PR in Jingo". It's more complicated than that.

[1] I am considering splitting Jingo in two: one would be an API provider for managing markdown files (more or less what Gollum does), and another one would be a client to consume the API: I can create a "complete" client for editors and a simple client just for displaying files, for example.

[strawhatgami]

I understand your point of view, and I didn't want to look angry or whatever when I wrote my previous post (my tone is maybe a bit dry or eager).

On my mind, I need to produce this code. I have then to options after developed what I want:

• keep it to me, as I do usually
• share with other, but share with precautions because of security concerns.

I tried the last option because I believed there will be enough people with enough spare time (not only you) to handle such PRs, and make them improve Jingo. Because it's one of the best not-Mongo-or-Cassandra-based wiki with advanced functionalities, as versionning; You've done a very good job with it, and that's also why I choose Jingo as a base for my code. Unfortunately, it looks I overestimate Jingo's community when I decided to submit my PRs.

I have no problem not to see my PR in Jingo, whatever the reason behind: in a sense it's better for me; moreover one of my main motivations was to help people behind Jingo to improve it, and if it causes more problems than it solves, this PR have no reason to be. So let's say I'll do a fork, but a private one for my personal needs ^^

I would be very interested to use Jingo when you will have realized your plans, and I hope some pieces of this PR could help you to achieve it (even if it's not the same goal, there are some similarities you can maybe exploit to avoid rewriting some code that you can borrow elsewhere).