initial rls will depend on several components of the overall project working together as-one.
That's not incremental release. That's release upon completion.
which highlights some of the complexities involved in a project of this kind.
Actually it doesn't really shed any light on anything. I assume you're describing a micro-services architecture? That being the case, you can release each micro-service individually before the next one is complete. What's more is you need not wait until the code is 'finished' to show your progress, and solicit feedback, and get other coders helping you to solve the tough problems. Doing so would greatly speed development, since then anyone could contribute instead of us just having to wait on one person.
to incrementally release part of a project would be the equivalent of building a house without the cement as an example, and then once the cement truck arrives we remove all the bricks and start again.. type-of-thing.. Systems are reliant on other subsystems.
If that's the case a micro-services architecture is almost CERTAINLY a bad idea, and you're much better off building a monolith first, and then scaling it to a micro-services architecture.
type-of-thing.. Systems are reliant on other subsystems. HTTPS stuff, the RPC stuff and the Nodejs/NWJS stuff which in turn relies on the mongo/Relic realtime & DB stuff..
That's... really a poor way of thinking about micro-service architecture. Protocols are just the lubrication for interoperation. Abstract that away FIRST, then never worry about how stuff needs to talk to each other again. Otherwise you'll just be doing what you just described forever.
so its like the middleware needs somewhere to get routed to and is kind of a way to do it incrementally after initial release has shipped... With P2P apps I cannot rely on LocalStorage as an example, I cannot rely on cache and write backs as another example these can all be leveraged in their own rights in certain sections of this project where applicable but the front/backend and client NWJS apps all need a place to pull/push their data to/from without the backend for example where will the rest of the apps pull or push to??
That's... not how DACs and blockchains work either. Kinda concerning...
Without the endpoints to direct data to or gather data from; if released without the complete picture would be like plugging in a power socket into a generator without any fuel. The lights are on but nobody's home kind of deal.
Yeah... well... we're all sitting in the dark now, so maybe some light in an empty house would be better than the void of blackness.
Its like having a altcoin with only the nodes working on testnet and no wallet.. that's probably the closest analogy I can come up with if I release it now.
Yes, that's how these projects progress: One step at a time. That would be a huge leap forward compared to what we have now.
They all rely on each other in some shape or form. The client and AM-X backend needs to know what block it's on to interact correctly with the network. And the client needs to also know which blocks to act upon/trigger as per events. if the BC is not talking to lets say the client then the client will have nothing to do but just to look pretty and wait for instructions. See where I am going with this.. All are crucial, all are interdependent but yet self contained in their own-rights as to be counted as separate applications, which all sounds contradictory but still true.
Well, no, that's how micro services architectures work. Each contains it's own state and all shared state happens at well understood boundaries. But why the need for such synchronization between distributed services? Seems like that's what blockchains are really good at solving to me... In fact isn't that THE inter-op mechanism? The blockchain itself?
There are methods which could be exposed internally, re-adjusted based from the custom aerome daemon build i done to allow for a very very basic example but its a waste of time and would look completely shit. not worth the time to do imho. The parts which are causing delays at the present moment are in the actual headers packets transmitted from the network to the client. To handle the SContracts data packets I needed to adjust how the client consumes normal blocks sent from the network and insert some extra frames which allows for the BC to manage the Smart-contract data-flows.
... are you making this stuff up as you go along hoping we won't ask any probing questions into the architecture?
its a pain in the ass as I do not have any reference to go by/from as a working example. The offerings which are out there presently only explain to me a limited portion of the problem and not the complete picture which I am having to work through. NXT have used a similar mechanism to accomplish what I am in the process of achieving so that helps a great deal. I am relying on my memory from the JEE stuff I used to do to work out / reverse a section from their work and port it over to AM-X specifically the SC portion which is only a few lines of code.
Well actually there's a ton of great examples in production now... you're WELL behind the curve with the offering at this point since other DACs have these features and many others, and you aren't exactly doing a lot of bolster investor confidence with this kind of post.
