search

RocketChat / Rocket.Chat

The communications platform that puts data protection first.
https://rocket.chat/
Other
40.61k stars 10.62k forks source link

Rocket.Chat -- Editions #1741

Closed Sing-Li closed 8 years ago

Sing-Li commented 8 years ago

Rocket.Chat Editions

Rocket.Chat community -- your input and ideas are requested.

Rocket.Chat has been growing phenomenally fast since its inception. Both in features and community size.

As Rocket.Chat continues its dual-growth trajectory in 2016, the single edition approach may no longer be able to satisfy the requirements of its diverse users community.

Take as an example - while the recent addition of the (very large) LiveChat feature is a key to many users' adoption for Rocket.Chat; it has also been an unwanted burden for other users who may have no need to handle customer service.

Another example is the myriad of included single-sign-on schemes, with LDAP and SAML (being the most complex and large) that users with simple servers installation may never have any need for.

Coming up soon, are features that can control access via complex policies, plus log and audit every single operation performed within the chat system. These are features that are championed by the corporate sub-communities of Rocket.Chat, while despised by the pro-privacy free-and-untethered installs sub-communities.

Most relevant to myself personally, Rocket.Chat is no longer able to run on the original Raspberry Pi. And installations on 512 MB VPSes often crashes during normal operation due to "out of memory" condition.

It is clear, ONE SIZE NO LONGER FITS ALL.

It is becoming increasingly necessary to build, test, and maintain multiple Editions of Rocket.Chat.

The initial proposal is to support at least the following editions:

But we would like to hear more about what you think about all of this before further planning.

Please comment and discuss.

neurobe commented 8 years ago

Edition: Payload - for non-chat centric, new, business oriented apps for which RC provides

engelgabriel commented 8 years ago

I like the idea, but the Community label alone doesn't say much. I'd go for:

or... we should be able do dynamically load packages. That may be possible with the new Meteor support for NPM.

graywolf336 commented 8 years ago

I would like to see the more modular approach be the route we go. I foresee there being a setup "wizard" when first ran and you can check the features you want enabled.

On Wed, Dec 23, 2015, 6:20 PM Danijel Cole notifications@github.com wrote:

Great idea. For my use case, I'm looking for a minimal RC package. We have a group based application already, we just want to plug RC into our existing group system to enable team conversation.

I was just about to fork and reduce the code-base for my own purpose. But if you guys are planning to make RC more modular, I will wait. I'd love to help if i can, although CS makes it much harder for me to do so.

— Reply to this email directly or view it on GitHub https://github.com/RocketChat/Rocket.Chat/issues/1741#issuecomment-167012817 .

Sing-Li commented 8 years ago

@neurobe , @engelgabriel , @dcworldwide - thank you for the valuable input. I have updated the list of editions to reflect your comments. Please review.

Rocket.Chat community -- additional ideas and comments are welcomed.

neurobe commented 8 years ago

I am embedding my app into RC, rather than the other way around. This might be only possible for new apps (hey, there is a new app born every minute), but still, I think it differentiates RC from other less well structured chat apps. I am utilising RC's user management (and multi-language support et al) and will use its text/voice/video chatting, but that is not the raison d'etre of my app - which concerns health devices and giving the practitioner intimate access to both the client and the equipment. More generally, this app might fall under the category of 'distance education'. There will be several slide-in panels associated with the technical control of the device. And I envisage that the main center page will switch between a chat window and the core display associated with the application (again, there will in fact be a couple of these windows). When this main window is switched it would be nice to be able to continue the chat in the slide-in window. As an aside, I am 60+ and new to web technologies. Thought I might have been biting off more than I can chew, but RC came to my rescue. Thank you. As a further aside, you may be interested to know that I am shoveling around data streams of 16kbps real-time continuous using arunoda:streams. No special buffering, just works, beautifully.

neurobe commented 8 years ago

Also, should not forget RC's multi-platform, multi-deploy infrastructure that I intend to ratchet. Wow. All in all RC provides a bunch of infrastructure that is highly appealing to independent devs of modern apps I would think.

Sing-Li commented 8 years ago

OT: wow @neurobe! Thank you for sharing. Comments like that mean a lot to us. The rest of the core-team will be on cloud 9 when they read it in a few hours. :smile:

neurobe commented 8 years ago

I'm not sure whether the "OT" tag means I'm not getting thru here. To take another tack, I think that independent devs (or wannabes) of multi-player games might very well light a rocket under RC :rocket: when there is an understanding of what it (and Meteor and Meteor Streams) bring to the the table. This is to underline that, IMO, RC-as-host to embedded apps has huge potential, together with what was alluded to above as "distance education" apps. How does this or would this impact on RC architecture? Well, time will tell I guess. For myself, I need the ability to move the chat window aside, and to have an Action Manager to provide an interface between RC and the Payload app. Not sure I understand what it is, but out-going webhooks might be getting close, perhaps a subset of what I had in mind. +1 for "RC-Host" (of payloads)

engelgabriel commented 8 years ago

Hi @neurobe

I fully understand what you are saying, and I am very aligned with the idea of Rocket.Chat as a platform.

I have seen the glimpse of it on the new HitChat... see the article below: http://www.businessinsider.com/atlassian-hipchat-uber-integration-chatops-2015-12

neurobe commented 8 years ago

There you go! So I see that "Chat Ops" has a wider interpretation than I had understood from reading posts here. HipChat might be targeting a few shiny apps to integrate (at least as a lead up to the IPO :smile: ) but it seems to me that for general applicability as a chat "platform", the client of the platform will need to modify source a bit to get what they want. Now how many chap apps are good and open source? :smiley_cat: So, how to facilitate this hosting of disparate payloads? I'm at the edge of my known universe here, but if "webhooks" encompasses the notion of extensibility as I think it may then I guess we are good: extensible input stimuli, and extensible output actions, accessible to disparate packages. I need a Calendar as one of the stimuli and there is $500 bounty sitting there for the next 6 weeks or so, at which time I will need to mash it up myself. It won't be pretty, and wont be part of a wider "Chat Ops" story, but will probably do the job for me. So I hope someone with a little more talent than me gets in first.

engelgabriel commented 8 years ago

We will take a look at the calendar soon, and we pretty much embrace the notion of extensibility for payloads. :)

Sing-Li commented 8 years ago

@neurobe ... OT = Off Topic ... :smile:

Certainly - we aim to become the chat/communications platform of choice with a large eco-system of apps. That is even our headline slogan on the website for the last few months.

sampaiodiego commented 8 years ago

just to share some numbers I got. I made two builds of rocket.chat, with and without livechat package and get this:

About the tarball size of the build: with livechat: 23140050 bytes without livechat: 22692793 bytes ( -447257 bytes = -1,93% )

Browser loading: with livechat: image

without livechat: image

Total transfered: with livechat: 844KB without livechat: 835KB ( -9KB = -1,07% )

Loading time: with livechat: 1,07s without livechat: 1,02s ( -0,05s = -4,67% )

so, I think it's fine to add livechat package as default.

Sing-Li commented 8 years ago

Thank you, @sampaiodiego , for the helpful quantitative stats!

It definitely looks like there is NO NEED, at least for the next few months, to disable LiveChat on Editions that should include it.

To summarize, the revised list of proposed editions are:

Rocket.Chat community ... please keep those comments and suggestions coming. We're wide open for your ideas on this one.

Megatronic79 commented 8 years ago

@Sing-Li assuming all editions will remain opensource and free? - other OSS products when using the editions "Pro or Enterprise" usually start charging for that version?

Sing-Li commented 8 years ago

@Megatronic79 Yes. The intention is to keep the editions, "Pro or Enterprise" included, open source and free.

Support for all editions will be exactly the same as it is today. Community support plus optional professional support (from our community members as well as direct from Rocket.Chat).

Recent global-scoped FOSS projects have found great success with this model.

Megatronic79 commented 8 years ago

Thanks @Sing-Li

+1 for dynamically loading of packages, think this would be a great option.

Sing-Li commented 8 years ago

@Megatronic79 - at this time, Meteor does not load packages dynamically. By design, Meteor packages are configurable only at build time.

We can engineer such a mechanism specifically for Rocket.Chat --> #1485, or wait for MDG to solve the problem (some Meteor community members already have some success with hacking webpack ). And MDG is trying to integrate at some npm level in 2016.

We have also considered the possibility of hosting a custom-build-service that performs customized builds on-demand.

More thought is needed on the combinatorial support matrix implied by such approach, as well as how realistically useful it may be - unless every features package comes with some "tested and well-documented" resource [compute + memory + db vs # of users] and dependencies profile.

neurobe commented 8 years ago

feedback on RC usage. For my project I currently envisage up to 10,000 private channels each associated with an individual IOT device and 1..3 registrants per channel. No more than 5% on-line and active at any time. That is, the approvals mechanisms for private channel access will also be used for accessing the data streaming from the device. Chat inside this private channel will be occasional, whilst data streaming to and from the device frequent. (Of the 6,000 devices we have in the field today, we expect 2,000 of them to be able to switch over to the new RC software immediately.) Supervisors will create a set of private channels for their clients. They have admin rights over the channels they create. Given that on occasions Supervisors will have control of 100+ private channels it would be nice to be able to group/sort/search or filter them - I think there is an RC issue open to searching public channels.

If there is something that someone sees is needed before this can happen, then I am happy to put a bounty on it. (Aside: a map showing location of those currently on-line would be a nice slide-in panel to have - think it go mentioned in the early days..)

Versions will run on embedded processors (ie smart toys (as client) and micro-computers HDMI dongles (as server)) as well as tablets and PCs. Don't see issues in doing this - instances of headless toys (as client) which don't need chat capability (the toys won't be that smart), but rather needing data streaming only maybe can exist outside RC as a standalone app, but then again a major point of the all this meteor stuff is to have a single code base. Live Chat: not needed Calendar to schedule events: needed Thanks.

haceru commented 8 years ago

Greetings all, and thank you for the great work you are doing !

We are looking into using RC as a framework / platform to build on for a direct democracy (e-democracy) voting application and for this purpose, the modularity / custom built "setup wizard" approach would be awesome (like @graywolf336 suggested). Also, the planned npm support would make our life much easier.

Great work and great suggestions, Thank you !

engelgabriel commented 8 years ago

There is this https://github.com/RocketChat/Rocket.Chat/issues/1859 thread discussing the ideal of a package system. Maybe we should merge this issues?

epatpol commented 8 years ago

I agree with the dynamic modular approach, I think it would allow admins to specifically configure their instances the way they want. I don't even think a wizard is needed in most cases, simply a configuration file with the modules to enable/disable would be good enough in my opinion (I'm coming from inspircd so that's why I may be biased towards a simplistic solution).

Wouldn't that approach also make it easier for 3rd party developers to make their own modules/custom commands? I'm not familiar with the rocket.chat code architecture and such, so pardon me if I'm asking.

engelgabriel commented 8 years ago

Wouldn't that approach also make it easier for 3rd party developers to make their own modules/custom commands?

That's the main reason.

engelgabriel commented 8 years ago

Lets close this discussion about and concentrate the conversation at #1859 as it seems the way we will accomplish the modularity we want.