Create a "skeleton" module set for new data sources

[jasonmunro]

We have had a few requests to add new E-mail protocol support (jmap, ews). This can be a big task, but could be made easier if we built a "skeleton" module set that had all the boiler-plate modules one would need to add a new data source. It could just return static data or do nothing, but it would make it much easier for a developer new to our module system

[Yamakasi]

I would not create it for new data resources, I would create it for all resources so indexing, searching, etc... is call a function in the proper mailstorage module. But that will be indeed a lot of work but will make it the best.

[dumblob]

...but will make it the best.

I can't comment the proposal technically right now, because I simply didn't look into it, but I'd like to point out we shall not declare any solution as "best" nor anything strong and clear like that and we shall be rather very careful with our wording as the whole IT domain in general is just a huge pile of compromises and suboptimal solutions (even such a thing like Haskell and other "pure" languages is clearly suboptimal from many points of view, even though it's pretty much pure mathematics - but it ignores many sides of physics and development processes etc.).

So, I'll repeat myself, please be very very careful with wording.

[Yamakasi]

In flexibility it will be the best solution, every dev can add whatever source he wants to use. Cypht only needs only need to maintain the "skeleton" and it's own supported modules.

There is always a best way in the current circumstances , the other question is, is it worth full and/or doable in the current circumstances.

I'm kinda direct in what could be a good future change, let me repeat myself... could be. If you are not clear what could be this good change you can be endup in lost time when you are finally where you would have want to be in the first place, which happens in the whole IT domain also a lot.

Sometimes it's hard to hear but if everyone sees the effort in it you can team up, otherwise it will be a long road I guess.

[dumblob]

I think I understand your concern @Yamakasi . But your argumentation and good will doesn't qualify for writing a clear nonsense (I believe you meant it differently, but just used an utterly wrong wording). Let me show you.

You wrote:
There is always a best way in the current circumstances...
We all know, there are some postulates regarding the "current circumstances". At least the following.

1. we develop the solution (any part of or the whole Cypht) for use in a moment which happens at least later after now ("now" being a derivation at the current point in space time; might happen this derivation doesn't exist, but it doesn't matter for this case), because first then (after the implementation took place) we can deploy it (and use it etc.)
2. we don't know the future

=> It's NOT decidable what the quality (e.g. is it the best or not under our circumstances) of the particular or whole solution will be as we don't know a bit about the future, but still we're developing it for future (not for now - that's the infinitely short derivation from above, like e.g. the Dirac delta function though not at time 0; we're also not developing it for the past as it doesn't matter any more).

So, let me again repeat myself, please be very very very careful with wording.

[Yamakasi]

@dumblob maybe you can stop this flamewar yourself, you want to have the last word in everything it seems with nonsense statements.

About the last word, and you naming "we", I have seen you mentioning lots of things and never commit anything so far or actually taking the time to find something out or test it out.

For me it was only possible to see how I could fiddle Cypht in over the past months on a side track as it was not designed for integration or real multiuser use, so please don't try to get me on that part. I knew when Jason was busy and he was not, so over time we came to what I can test fully atm

So please stop this flamewar by overthinking your own words and add something useful here.

[marclaporte]

For the record:
#247
https://unencumberedbyfacts.com/2019/01/24/jmap-its-like-imap-but-not-really/
#180