I know basically that he is trying to solve the issues of how to interface modules and APIs with typed objects. Me too. He has his formulation and I was working on different one which would I think be more elegant and attract more app developers.
The more elegant formulation is what im looking to do now. The three choice are : Doing the high level ui part in js, and all app with js, only the low level part in C. Doing a script language to implement rpc/json interface. Eventually doing call to lower level API. Doing c++/com interface to program app / modules in c++, and keeping json glue code for rpc remote calls . ( to do js app on top of it), or use COM runtime for Microsoft app for higher layer (vb/c#/js in IE). It's hard to get on coding something without choosing some language, and the definition of the interface need to take in account implementation in the languages too. Doing all in node.js is yuck too, and in the end for blockchain related things, im not sure it would even be that faster to write than C with different part requiring the equivalent time. And js has weak error checking in "pre run time". It can create faulty code very easily. It puts lot of pressure on the transpiler if it's the way used to produce the js code. If your goal is to make a script language with modules & OO that is close to js, im sure can get interpreter for the basics quickly. Basics is Parsing of json object Api call Simple evaluators for expressions like int a; String yy; Float xx; obj b={"key":value}; obj Obj; a=b.key; If (a>100) ApiModule.method1 ("toto"); Else ApiModule.method2({"key2":param}); Obj=ApiModule.getObjectRef (); Obj.value=yy; XX=Obj.value2; I will not necessarily do the conditional branching like this, but all the code to evaluate expressions like this and events is already made, the script would be running on top of node in standalone executable And its possible to have static type for value & objects with the modified json synthax that the api recognize, and automatic type conversion.. . And its not too hard to get to a full implementation of json/rpc interface with a script language like this. And all the low level code is already made, to deal with p2p network packet, blocks / tx validation, object serialization / hashing ,and to manipulate wallets or block explorer and raytracing via http interface useable with json/rpc or cgi style. More complex expression and runtime to handle list can be thought of, but list processing can be made in C. Or can have equivalent of map/filter/for each loops, in the script to deal with lists of objects. Filters can be made with simple expression evaluation, and I have the code to filter block list based on query string expression. Map can be made with module api calls. Other kind of list processing can easily be made with the C framework interfacing with json. If you prefer to do your thing on your own, ill work on this by myself the time you get to something equivalent or better., but my objective for the moment it's this, getting to more elegant formulation, i have different solutions to get there in reasonable time. |
|
|
|
In the absolute to do something based on com & IDL, it would be easy to come up with something like this :
Class myModule : IDL_INTERFACE
{
Int method1 (int a, string b)
{
mem_zone_ref params={ptr_null};
create_obj (¶ms,"params",type_json_object);
set_key_int (¶ms,"a",a);
set_key_str (¶ms,"b",b);
module_call ("myModule", "method1",¶ms);
deRef (¶ms);
}
}
IDL_interface *myInterface=new MyModule ();
myInterface->method1 (18, "toto" );
Or the opposite
Class jsonRPCHost
{
IDL_interface myInterface=MyModule ();
JsonResult method1(string jsonParams)
{
mem_zone_ref params={ptr_null};
Int a;
String b;
tree_from_json (jsonParams, ¶ms);
get_key_int (¶ms,"a",&a);
get_key_str (¶ms,"b",&b);
myInterface->method1 (a,b);
deRef (¶ms);
}
}
jsonRPCHost rpc;
rpc.method1 ("{a:18,b:\"toto\"}");
Or can do same for passing parameters as json array instead of named values. rpc.method1 ("[18,\"toto\"]");
To have binding between com interface , json/rpc interface, and the binary modules. The code to extract the parameters need to be changed, rpc support the two modes, with my code it detect if the json is an array and the module need to adapt the params parsing if it use array or named values. By default it use an array for the moment, but using named value would allow to pass directly jsonified js objects to the rpc on the client side, here the js api build the array out of the js object for the rpc. generic module call in C
tree_from_json ("{a:18,b:\"toto\"}", ¶ms);
module_call ("myModule", "method1" ,¶ms);
the name of the method can be extracted from the full json rpc request. with "mod.method" synthax in the rpc request, the runtime function executing the call to the module method could make the call automatically with generic code for any rpc request . For the moment it use http url path to determine the module name, and the config file bind the http path to the module interface, either it's used as a cgi and extract the parameters from http query string, or with the rpc interface, both can be used. The block explorer use the cgi api with parameters from the http query string, the wallet use the rpc api. In any case, the module call can be made to local module, or to remote module via http/rpc/request, the C synthaxe just remove the boilerplate of c++ object definition, and in the end the c++ interfaces just translate parameters to/from json to c++ compiler specific data, to potentially retranform it back to json to make rpc call. The c++ interface definition just add boilerplate, break binary compatibility, and is not even very useful from js app point of view. Can make développement of module easier using c++ synthax, but that's about it. And I dont think can expect opengl C++ app too soon anyway. And other than for doing opengl app,the js api can do it, and it can still somehow handle opengl even if rpc call are slow. Maybe for programing pure server side modules without UI, it could be useful to have c++ layer to make code typing faster, but it raise certain question with error checking & c++ operators. Without using exception I dont see how to check operators error, and without operators it would end barely less fugly in c++. For the interfacing glue code can be made to interface c++/com with json for js rpc & other modules. But doing an interface to handle inter object operators is not easy. And then the module execution cant be distributed because of the operators instead of using the C synthax. With a bit more work it can embedded into IE, and script in vb,c#, and js with ie ( without rpc interface, with com runtime ), but that work only for Microsoft stuff. The equivalent of this is XPCOM which is supposed to be more portable, ff & chrome & safari can use those, even if chrome is dropping it, and will develop something else, safari have their own native plugin format, but it support the XPCOM thing. But even under linux, it's not widely used to develop application, it's mostly used by browser, to define the DOM objects, and the plugin, but outside of flash the other plugin are marginal. So in the end this can be third way to develop more a COM/XPCOM like approach in c++. Im not sure how far IDL can go with design pattern, I think you can at least define method who deal with other IDL interface, there might be way to define complex type but not sure, most likely conversion from json object to c++ method parameters need to be done manually with json object members passed manually with the good order to the IDL interface method. To have something similar to c++ operators with COM , you would have
StringInterface *A;
IntegerInterface *B;
Int value;
A=rpc->getStringInterface ("1234");
B=A; // automatic operator overload defined in the interface, return the interface to an instance of B
value=B->getValue (); // rpc call
B->deRef (); // rpc call
If A and B implementation are hosted remotely , it mean the host need to keep an instance of B as long as the client needs it, and it make three rpc request to have the equivalent of operators. And you could get to Value=A->B-->member [xx]->method1 ().result.value; With rpc call each time, but it's hard to have good error handling, or asynchronous requests with a synthax like this in c++. If one call return invalid object interface, it mean most likely crash. And it's not always possible to know if the function will succeed with remote calls. So in the end to have something safe , it will always be fugly in a way or another. In C you can get same operation in one call with explicit typing
Json_to_tree ("\"toto\"",¶ms);
module_call("A","getValueToInt",¶ms,&value);
// params contain eventually data used by the operator
// or the operand like B represented as json object if the operator use the value of B
// value is the return value represented as json object or in binary form if the return type is explicit in the module call declaration.
But it need to make each call step by step with fugly synthax. There is a single rpc request , and no boilerplate for the api call itself, but boilerplate in the code to manipulate the binary json object from C. ( but again the code is very safe, and hard to make crash, there will always be a meaning full answer to interface method call). Other than IDL I dont see other interface definition that has really practical advantage. But there is no really convenient easy way to force javascript to use a particular format out of an interface definition, or to have anyway to check the object that is passed to the rpc method call from js is the format used to define the interface in c++, or to check from js the result is the type it expect. My main concern is not optimisation but a language to program blockchain node must have good support for all these: network api, asynchronous io is a big plus, upnp is big plus http protocol, json, data format, compression, url & query string parsing, utf8 etc object serialization and hashing. Elliptic crypto. Database system. GC / ref counting is must. Simd vectorial math and opengl are a big plus. Good threading support is big plus. No need for virtual machine or interpreter is big plus. Easily work with html templating or integrated ui small plus, templating can be done in browser from json, or html can be made externally. With all this in mind there is not many language who fit the bill, and even without premature optimization once you are stuck with a language framework, there is not always good way to optimize much more, or work around certain bugs or deficiency in one area or the other. Other than C and C++ I dont see what other language can fit the bill, not even getting in resources uses, memory, performance, and access to local system/hardware resources, binary compatibility, etc |
|
|
|
Not to sound insistant but ..  Well again it's not to play smarter than you game or authority contest, but im bit code addict, if I dont have my dose of coding my hands start to shake & all, it's just know where you want to get at, and how to collaborate efficiently  not turning around the pot for ever, as you say talk is cheap  https://youtu.be/IQTgQ0PNGHU If you want to make language agnostic interface definition ok, but what do you have in mind to define them ? The only systems I know of to have cross language definition is COM and ns XPCOM, with the IDL file who can be compiled to different language to define the interface in the target language and being able to call methods implemented in the host module from the client application language. With COM then the object can be used with vb,c#,js, all language who support com interface, but it's hard core Microsoft stuff, on linux it's not so great. But ultimately for it to be useful, it need a way to implement both the host side of the interface in the host component language, and the client application side of the call in the client application language. Each languages will have their own internal representation of the data, if you dont understand this, you dont understand anything at the problematic of cross language interfacing. With c++ even if the two class are defined with the exact same code in the same language, but the class implementation are compiled with different compilers, there are great chances they cant call each other methods, even if the definition is the same just because of incompatbility in the compilers. And my objective is to make interface call either to locally hosted modules with regular local language call, either remote call via http/json/rpc if the interface implementation is hosted on another node, transparently for application. The whole point of my framework is to have a network of node who host modules who implement an interface/api who can be called either locally or remotely, and make it as transparent for the app developers as possible. You say im into premature optimization but if I had to state my main concern with the design it's more memory security, and binary compatibility. Actually albeit it's C code, you will see very little direct memory access outside of stack variables and strings. All memory access can be checked, with the runtime in paranoiac mode, you could fill the whole memory with junk and it would not crash. Even if it cant allocate memory it shouldn't crash. The code is made with the main purpose of having zero memiry exception. It's also the advantage of using regular C call with pointer to result because it can return a success/failure state additionally to the result, which can allow to detected case of invalid access without triggering exceptions, which is not really possible with c++ operators. In the end, between If (!tree_get_key(object, key,value))
{
// INVALID VALUE
}
Or Try
{
Value = object [ "key"];
}
Catch
{
// INVALID VALUE
}
You cant say the code is much better with c++ in the end to have same level of safety. Let say you want to have Try
{
MyAddr=peer [2].block ["xxxx"].tx [3].output [5].addr [0];
}
Catch
{
// INVALID value
}
You could easily come up with operators for different object implemented in differents modules compiled with different compilers, and having exception thrown by a runtime different from the one who is supposed to handle it, and ending in an happy mess. The best way i though to be able program c++ app with it is to have a c++ layer on the top of the framework, to have all the c++ synthax with overloaded operators , OO design, interface definition with c++ class, iterators etc, and the application developper deal himself with binary compatibility with the c++ code. As long as the methods are implemented on top level, at application level, and dont have to be used by other applications or distributed over the network why not. Or the trick can be to define the rpc interface with C export, extract the json parameters and use the c++ code inside, this can work normally, as long as the c++ code doesnt have to be shared, the c++ OO pattern is invisible at the interface level. My objectives globally is this, having node who expose API both to local or remote application, with memory safety on dynamic type and cross language interface ( which is different from language agnostic ), and having a way to program application easily in high level language using this distributed api. If you want to get in interface definition and all why not, but which format to use to be able to easily implement different side of the interface in different language easily ? Using com IDL ? XML ? Ultimately what js application developpers are interested into is the json definition of the object, that's the only thing they will be looking at. And im ok with perfectly immutable system and protocol, I can get the idea that blockchain protocol is not necessarily a thing supposed to evolve , but that would be true if we had the actual equivalent of blockchain mathematics to define the protocol once for all without any need to change anything in it ever. Thinking you ll have the perfect protocol right at the first time from scratch is foolish. So ultimately still need way to be able to upgrade the protocol as easily as possible, even if the goal is not to upgrade it at all. Especially if the protocol is more complex, need really to see the two aspect of bitcoin protocol, the network data format aspect, and the block validation algorithm aspect. 90% of blockchain use the same network data format, but different algorithm to accept/reject the blocks, so the protocol is not only about data format definition, but also about algorithm to validate those data. if an high level representation of a blockchain is to be though of, it need also to be able to represent the block validation algorithm, so most likely as some kind of script or code who define the block validity. If a reward scheme is to be implemented in the block validation, it would happen there, Even if it's mostly likely being below application level. But if it to program full blockchain node from scratch, and you dont have clear idea of the language or framework/sdk toolset to use, and you dont want to use my design which fit my purpose, but you dont know how to get the equivalent feature, I cant help you much lol i expressed all the concern i have with the current solution I know of, and why they are not fit for my purpose. Im all for layered design and design pattern, interfaces and all, but it has to stay within the scope of the feature im after for distributed application problematics. Having distributed application coded in bare c++ for me it's only trouble. Or it need a layer of glue code between the different part of application which i want to avoid. And there isnt really much true cross platform solution, even with c++. The closest is ns XPCOM. But I dont think it's even really supported much. Other than this it all come to hacking glue code somewhere in between to have interface who can share information represented in different format by different language. By manipulating json tree in C, with the safe memory representation and access, it solve all the low level interface definition aspect. Even if the synthax is heavy, it's still very simple logic. The code is long to write, but hard to do mistake, and the purpose of each function, the type involved, and return state are obvious and explicit. So after there is very short debuging time. Can add a parameter to the interface easily, recompiling the module, copying it to linux and windows machine, restart the node, done. Js application can then use the parameters. And only the module implementing the interface has to be recompiled, and only once for all win & linux machine on intel. C/C++ programs can share binary representation of the data via the tree api, and do direct module function call in the local process memory, and remote program or js program can call the function with json/rpc over http. All working on the same data format, with sur typing possible on the C side to differentiate between different json objects. But all the data in the C side can be turned to json and vice versa. So C/C++ applications can easily call module function indepently of the location of the module, and js application can call those same functions using it's native object format as parameter via http request. Knowing it's not so much about linear scalability than about asymetric repartition of resources across different nodes. My requirement is this, either to implement low level blockchain protocol, other protocols on top of it,or distributed application . And I dont see a better way to get there than the solutions im working on. |
|
|
|
|
But all together im sure it could be turned to c++ with much better synthax, even only using over loaded operators.
You ll notice the only thing it would need to encapsulate modules as c++ class is adding the class { } in the file, and removing the prefix in functiun name, and roughly you get a class definition out of modules, they are a single C file , it's thought to allow this easily, and macros/regexp could easily turn the tree manipulation functiun to a better synthax with c++ operators.
Like
tree_manager_get_child_value_hash(&last_blk, NODE_HASH("prev"), prev);
=>
Prev=last_blk ["prev"]
,
tree_manager_set_child_value_hash(result, "merkleroot", merkle);
=>
result ["merkleroot"] = merkle;
Etc With over loaded operators and type conversion.
( the tree_xx) function allow explicit type conversion, and are roughly equivalent of c++ operators, and they can be either just copying/passing a reference (by default) or being equivalent to copy constructors , and they can already allow looping like for each on array of json objects with the C synthax, it could easily be implemented as c++ iterators.
But ....
c++ operators function exported name is not compatible between compilers.
Object this call is not compatible between compilers.
Can make the compilation more complex on certain platform (like raspberry pi).
Can make complex type conversion implicit/hidden, even sometime hard to really express with c++ operators .
So for distributed application it's a bit bothering.
And anyway the real application is programmed in js, so it's better to have application driven data definition, and use json as base for data definution , in the absolute all the data format and protocol could be defined at run-time, loaded from a conf file or user supplied from the UI.
The c++ would just add synthax sugar to code that is supposed to be low level, while making compatbility with json data definition from application more difficult, because lack of compatbility in module interface implementation at binary level. And it wouldnt change anything to the synthax of the js code anyway, as it all happen through json/rpc.
The whole OO synthax sugar to manipulate data in the UI can be made in javascript with hardcoded data format to communicate with the node, and it doesnt have to know about nodes internal object representation, just the json encoding of the parameters and return result of the rpc request , no matter how the module interface is implemented in the node and which compiler has been used to compile it.
|
|
|
|
Just a question from a non technical guy. I haven't really read all that you guys wrote, but i've noticed javascript being mentioned. So why javascript and not webassembly ? Apparently WASM is superior, even javascript's creator brendan eich endorses it.
I just looked into it : http://webassembly.org/docs/web/Apparently it still need to be compiled to js to run in a browser. Can be interesting if it has good support for network protocol and crypto.
ABIs
In the MVP, WebAssembly does not yet have a stable ABI for libraries. Developers will need to ensure that all code linked into an application are compiled with the same compiler and options.
In the future, when WebAssembly is extended to support dynamic linking, stable ABIs are expected to be defined in accompaniment.My ABI already have this  and it support aligned simd 128 bits operation too and full native compatibility with C ( it's C ), cross compiler binary compatbility, dynamic linking, and json/rpc compatibility and I already have large part of blockchain protocol implemented with it. But it seem similar in the purpose to where I want to get at. The big advantage of js is that it has large base of code , sdk, programmers, support etc which is mostly what make it interesting. The only pb is access to local storage, and performance for binary data or crypto, for operating full node it seem a bit light. But for programming high level logic, UI, and interactive application, it's good. Just need to have simple design pattern or it can become dicey. With good naming convention and specialized object who are all horizontal it can be doable in js. But adding a layer in c++ or true OO just to have compile time design pattern in the node, where all the application logic happen in another layer anyway throught a rpc/json interface, seem a bit pointless. For me the two way are Either doing full OO script to define node and rpc interface to app , and eventually program some parts or all the app itself with it, or a synthax to export rpc method from the script code for other modules or js app. Either doing the OO layer with js and rpc calls. WASM seem to have a system like this to bind module interface to js api, but it doesnt seem to support http/rpc. Or to execute remote modules. With the js rpc it can execute code on remote machine. The thing with table/element definition in the modules to have data definition with WASM is replaced by runtime type definition based on json. So the data definition can be shared easily between low level and high level. No need for "glue code". http://webassembly.org/docs/semantics/#table
Table
A table is similar to a linear memory whose elements, instead of being bytes, are opaque values of a particular table element type. This allows the table to contain values—like GC references, raw OS handles, or native pointers—that are accessed by WebAssembly code indirectly through an integer index. This feature bridges the gap between low-level, untrusted linear memory and high-level opaque handles/references at the cost of a bounds-checked table indirection.
My system with explicit type added to json does the same than this, expect it's not opaque, and convertible to json, using json allowed typed string/integer/real/object/array. So the equivalent definition for module interface can be used also as the definition of the json/rpc interface. And it's never totally opaque. In worst case scenario such thing with array of element with binary ofset can be done with the tree system, but better to add named and typed sub members , in transparent structure that can be shared with js. The function arguments passing is the same for C program call (dll api), or rpc call (via http/json api)). Having internal compile time constraint for modules rpc interface is not necessarily a good thing, and it will be useless in any case for the application layer, unless the application layer language can understand those type. Which while not be the case with js. The best you will have for data definition in js is json and flaky runtime type. Unless you add a layer of runtime in js who is able to get the good class instance from high level definition, like a factory to instanciate complex class hierarchy based on runtime parameters to build an OO representation of the node and specialized class for each rpc interfaces/modules. But the data format will be hardcoded in a way or another in the javascript code anyway, independently of the node definition. You can just pick between different hardcoded format at run-time by using the good class instance corresponding to the node rpc interface. Unless you want to compile the js code with the hardcoded values from a definition also used to compile the node interface implementation , but it wouldnt give much security at run-time. Or can generate the js code to call the api at run-time based on module definition like WASM. But doesnt seem all that convenient. Having data definition based on json in the node's internal C dll-api is not the worst solution. And there is an api, it can compile as dll on windows or so on linux like in debug mode, with the dependencies and api definition etc, but the data format of functions parameters are defined / parsed at run-time, and they can be defined at run-time automatically based on json object. The API at the C level can be called directly via http/rpc transparently. C function parameters are sent with a json object instead of a C structure or list of parameters.The C code can check the validity of the data structure at runtime, and do it's operation safely on it if it has the good type / children, and return the data to the app in the same format via json/rpc. The only thing the compiler see is pointers and integers, but all memory access are checked at run-time. the http json is like a layer added to the call to handle remote access to the api, it turn the json parameters from the rpc request to the tree, call the exported function specfied in the rpc request method with this parameter, encode the result to json, and handle the http layer. From the js point of view, it's like directly calling the C function exported in the module. The rpc request method is the exported function name, The module is selected with http url path. The parameters are parsed at run-time by the module code from the json format. |
|
|
|
I guess my use of the word 'spaghetti' offended you. Sorry but I think writing high-level code for apps in C is not a good idea (because developers don't like to do that, it produces less readable code, reduces productivity, slower to market, etc). But I think we need to differentiate between the server-side and client-side. I suppose most of the code you are showing me is for a server-side full node. For the client side apps, I hope you aren't proposing to use CFor the app code, there i see two possibility. Either using javascript, and encapsulating modules rpc interfaces in js class. But the design pattern is still weak, but already good application can be made with html5/js . Or either doing another script language, who recognize the module interface/api, and can make call to these modules, to have better high level node definition, and building application with this script language. 90% of application is making call to modules interface and formating UI. If the script language can include some form of html templating , additionally to exchanging data via api, it could allow to program more of the application with this script language . Maybe programming in C for the warrior or if they need specific code that need to be done in C, but normally the idea is to have module already made to fit the purpose to be used by the high level app language. For certain real time app like 3d video game or opengl the http/rpc can be too slow, if the app still need to have real time connection to the blockchain in lower level language. The part of application to be made in C / c++ or js is up to each developper. Most webapp should be made with js. For purely blockchain related stuff , the wallet rpc interface and block explorer should be enought with the in browser crypto part in js. Normally most operation that can be done on a blockchain by an application is implemented in those modules with the regular rpc api and block explorer api. Other module are to implement other interface for other type of application, but the logic can be either programmed in C or js, knowing that with in browser js, there cant be local data, all the user data has to be handled via a module interface. ( either it's on a local node or not). But outside of code that need to store permanent data, it can be programmed in js too, but js is not necessarily good for doing complex parsing on long list. So complex parsing / filtering etc is better done via C modules. And really the synthax is not so bad, there is not too many key word it's mostly tree_set_child _value_type (object, key, value ) ; and the gets. It's to manipulate json tree in C with reference counting etc. But such tree can be translated to/from json in one line. Either it's to build them out of rpc/json request, or output the json result for the javascript app. As most of the node operation even low level stuff use this tree structure, js app can plug anywhere in the internal api with json/rpc call. Only the very low level things like kernel level io or sockets really need to be done in C. But parsing thousand blocks and tx in js, not good idea either As all the data manipulated by the node internally use this structure, all the internal "DLL based api" is also the "rpc/json api" . Without there is anything special to do. The function dont make a difference if it's call from another C modules, or a js rpc. The data format is the same for both the call argument, and the result data . Both the C program and js/rpc works on the same api. The http server just load the json parameters of the rpc request to the tree, and tranform the result tree to json for the rpc/json. Whereas the C app directly sent argument using the tree and parse functiun result from the tree, instead of using json. But internally it's same than old school dll api, expect parameters and data is defined dynamically as json data tree, and the compiler is blind to it. ( but not the runtime). Any level of hierarchy of array of object can be represented like this. By object I mean object in the json sense, a collection of named value.
|
|
|
|
Loading precompiled modules it's called dynamic linking DLLs are already supported by the OS. Well i made my own dll who can be made from so or dll, and can be loaded and linked on both linux and windows, independently of the compiler. The goal to have module is to like a static class
That is not correct English grammar. It is difficult to understand your writing. Sorry lol im typing on the tablet What I mean is to have module definition used as static class. A collection of methods, and unique instance of data. , and they can be moved from linux to win without recompilation.
Yeah I read that on your site, and I don't understand what is the worthwhile benefit. Developers know how to use compilers. Do you want to dynamically load this over the network? Why? And code trust may be an issue in that case depending on your use case. For linux binary compatibility can be an issue, and binary often have to be recompiled for each machine. And like this it's 100% the same binary code running on all nodes. The code trust can be solved with verticalisation and private network like I explained before. The main concern for doing these module is not for this project, but I think they are useful here, to deploy easily distributed application, it remove the burden of compiling. And can provide good abstraction for interface definition, and as they can deal with json data, they are fit for json/rpc. A module implement a json/rpc interface. The point of doing a script language is to have synthax improvement on the C.
That is what I thought. You are trying to model OOP in C instead of using a more appropriate language, all because you want this dynamic linking of code? It is the holistic reasoning that I am not getting. I don't understand why you would choose to make these design decisions. Not really oop, I know the limit of C with this, but for interface definition and encapsulation the module does the trick. Full oop need to be done in another layer. Or it can be directly exploited in js, adding the OO synthax with js class definition. Api cannot be language agnostic as they need to take in account the functions call parameters and the types of arguments lol
An API can surely be language agnostic. REST APIs are language agnostic. They use XML. If the language you use dont support XML, you cant use it. If your language has certain limitation on data type, it can be unsafe. Using json can pass language agnostic data, but the language has to parse it, and with compiled languages structures or class cant be made at run-time with the members of the json object.
Orthogonality (separation-of-concerns) does have a performance cost. But premature optimization is bad design. Im not hacking stuff together like spaghetti lol there is design pattern, modules, typing, interface, api, etc.
Really premature optimization is spaghetti. You may have certain features, but that doesn't mean the priorities of how you achieved them are not spaghetti. Spaghetti is conflating things which should be remain orthogonal until there is an overriding justification for conflating them. Also OOP as in subclassing, is an anti-pattern. Not saying you have that feature (subclassing, i.e. virtual inheritance with subtypes). Where am I talking about optimisation ? |
|
|
|
@iadix, I did not yet finished trying to figure out what you are doing with your code. I see you are doing some strange things such as loading precompiled modules and some scripting concept which I don't yet see the relevance of. I was too exhausted when I was looking at it. Had to sleep. Woke up and was finishing up my analysis of blockchain economics. Now I need to prepare to go for a doctors appointment which will consume 6 hours because have to get xrays first.
So then when I return, I will probably be too exhausted to look at your stuff today.
I will say that the code of manually building these JSON objects looks very fugly to me. And coding everything in C seems not ideal and not programmer friendly. We need C only for code which needs fine tuned performance, which typically is only a small portion of the overall code.
There is TypeScript for static typing on JS.
I will read your last message later as I don't have enough time right now.
But again I really don't understand the overall point of the JSON stuff. And I don't understand why you claim it is optimal to conflate the languages used to create programs which implement the APIs. APIs should be language agnostic. Good design is to not prematurely optimize and commit to a language.
Sure seems to me that you are probably conflating things instead of building good APIs. But I need to think about this more before I can definitively respond to you. I am still open minded.
My goal is not to prove which one of us is more clever. I simply want to design the systems that will scale (and I mean scale in terms of programmers adoption of our platform thus obtuse frameworks are not desirable, not just the other meanings of scaling). And to balance that with needing to get something launched asap.
I put a lot of effort into correct layered design. I don't believe in just hacking things together like spaghetti. I don't understand what APIs you claim you have designed and why you claim they are optimal? I don't even understand yet the significance of your tree concept. It is as if you are trying to build an object system in program/library code that should instead be integrated into a programming language. Perhaps I just don't yet grasp it holistically.
Loading precompiled modules it's called dynamic linking There is no scripting in this code. The goal to have module is to like a static class, and they can be moved from linux to win without recompilation. Json object can loaded from json text, the tree_manager_set_child_value (node, "xx",value) is like hash key list. Like node["xx"]=value. It's the same than to have hash table. But you cant have in C load_json ("{key:value}",&xx); and then xx.key, like in as3 or js . because static type so it's read_node_child(&xx,"key",&value); The point of doing a script language is to have synthax improvement on the C. Api cannot be language agnostic as they need to take in account the functions call parameters and the types of arguments lol even with XPCOM api definition are compiled from IDL to the target language. I could write interface definition, but if it's to have interface definition in json, to define an interface with json parameters, the api definition is just decoration at programming level. The json is the api/data format definition used by the json/rpc api. I dont see the point of defining interface otherwise. To have IDL like thing, compiled to json ? Or compiled to C header to load preformated json ? Using json can pass language agnostic data, but the language has to parse it, and with compiled languages structures or class cant be made at run-time with the members of the json object. Im not hacking stuff together like spaghetti lol there is design pattern, modules, typing, interface, api, etc. But ok ill take this as ill have to build application for a non existant blockchain made with a non existant language who is so agnostic that it doesnt exist. So ill let you at it and keep doing application with my thing But my goal is to improve the synthax, and modules in my mind they are more for the low level operation. And the high level part in js. Or adding à icing in c++ even if id rather leaving the scripting in other language. Anyway most of programmable part is made in js. Module they are mostly to implement the hard part to remove it from js app, but still able to parse json/rpc request and output json result. Can make definition of the rpc interface, but it's useless at programming level. The compiler is blind to the api. It's more like as3/js, object and type are build at run-time based on data definition. It's the implementation of wallet rpc api https://github.com/iadix/purenode/blob/master/rpc_wallet/rpc_methods.c
function rpc_call(in_method,in_params,in_success)
{
$.ajax({
url: '/jsonrpc',
data: JSON.stringify({ jsonrpc: '2.0', method: in_method, params: in_params, id: 1 }), // id is needed !!
type: "POST",
dataType: "json",
success: in_success,
error: function (err) { alert("Error"); }
});
}
The js wallet : https://github.com/iadix/purenode/blob/master/export/web/wallet.html
function import_address(address) {
rpc_call('importaddress', [address], function (data) { });
}
function get_addrs(username) {
rpc_call('getpubaddrs', [username], function (data) {
$('#newaddr').css('display', 'block');
if ((typeof data.result.addrs === 'undefined') || (data.result.addrs.length == 0)) {
my_addrs = null;
}
else {
my_addrs = data.result.addrs;
}
update_addrs ();
});
}
function import_keys(username, label) {
rpc_call('importkeypair', [username, label, pubkey, privkey, 0], function (data) {
get_addrs(username);
});
}
Complete api for the rpc wallet in js http://iadix.com/web/js/keys.jsAnd for the block explorer http://iadix.com/web/js/blocks.jsImplemented in : https://github.com/iadix/purenode/blob/master/block_explorer/block_explorer.cOS_API_C_FUNC(int) getlastblock(mem_zone_ref_const_ptr params, unsigned int rpc_mode, mem_zone_ref_ptr result)
{
mem_zone_ref last_blk = { PTR_NULL };
if (tree_manager_find_child_node(&my_node, NODE_HASH("last block"), NODE_BITCORE_BLK_HDR, &last_blk))
{
mem_zone_ref txs = { PTR_NULL };
char chash[65];
hash_t hash, merkle, proof, nullhash, rdiff,hdiff,prev;
size_t size;
unsigned int version, time, bits, nonce;
uint64_t height;
memset_c(nullhash, 0, sizeof(hash_t));
if (!tree_manager_get_child_value_hash(&last_blk, NODE_HASH("blk_hash"), hash))
{
compute_block_hash(&last_blk, hash);
tree_manager_set_child_value_hash(&last_blk, "blk_hash", hash);
}
tree_manager_get_child_value_str(&last_blk, NODE_HASH("blk_hash"), chash, 65, 16);
tree_manager_get_child_value_hash(&last_blk, NODE_HASH("merkle_root"), merkle);
tree_manager_get_child_value_hash(&last_blk, NODE_HASH("prev"), prev);
tree_manager_get_child_value_i32(&last_blk, NODE_HASH("version"), &version);
tree_manager_get_child_value_i32(&last_blk, NODE_HASH("time"), &time);
tree_manager_get_child_value_i32(&last_blk, NODE_HASH("bits"), &bits);
tree_manager_get_child_value_i32(&last_blk, NODE_HASH("nonce"), &nonce);
if (!get_block_size(chash, &size))
size = 0;
get_blk_height(chash, &height);
if (is_pow_block(chash))
{
SetCompact (bits, hdiff);
get_pow_block (chash, proof);
tree_manager_set_child_value_hash (result, "proofhash", proof);
tree_manager_set_child_value_hash (result, "hbits", rdiff);
}
else if (get_blk_staking_infos)
get_blk_staking_infos(&last_blk, chash, result);
tree_manager_set_child_value_hash(result, "hash", hash);
tree_manager_set_child_value_i32(result , "confirmations", 0);
tree_manager_set_child_value_i32(result , "size", size);
tree_manager_set_child_value_i64(result , "height", height);
tree_manager_set_child_value_i32(result, "time", time);
tree_manager_set_child_value_i32(result, "version", version);
tree_manager_set_child_value_i32(result, "bits", bits);
tree_manager_set_child_value_i32(result, "nonce", nonce);
tree_manager_set_child_value_hash(result, "merkleroot", merkle);
tree_manager_set_child_value_hash(result, "previousblockhash", prev);
tree_manager_set_child_value_hash(result, "nextblockhash", nullhash);
tree_manager_set_child_value_float(result, "difficulty", GetDifficulty(bits));
tree_manager_add_child_node(result, "txs", NODE_JSON_ARRAY,&txs);
get_blk_txs(chash, &txs,10);
release_zone_ref(&txs);
/*
"mint" : 0.00000000,
"blocktrust" : "100001",
"chaintrust" : "100001",
"nextblockhash" : "af49672bafd39e39f8058967a2cce926a9b21db14c452a7883fba63a78a611a6",
"flags" : "proof-of-work stake-modifier",
"entropybit" : 0,
*/
return 1;
}
return 0;
}
The json/rpc method call are directly module function calls. This is the rpc/json api. But it's defined at run-time. But tree can be built automatically from json string in one call. And json string from this tree too, it's the interest. |
|
|
|
For me, where i want to get at, is to get a definition of node that would look like this : {
"node" :
{
"name":"purenode",
"seed_node_host":"iadix.com",
"seed_node_port":16714,
"p2p_port":16819,
"magic":0xD9BEFECA,
"version":60018,
"sign_mod":"ecdsa",
"pubKeyVersion":0x19,
"staking":
{
"staking_kernel":"stake_pos3",
"target spacing":64,
"target timespan":960,
"stake reward":150000000,
"limit":0x1B00FFFF
},
"mining":
{
"target spacing":64,
"target timespan":960,
"limit":0x1E0FFFFF,
"reward":10000000000000,
"last_pow_block":200,
"paytxfee":10000
},
"genesis":
{
"version" :1,
"time" :1466419085,
"bits" :0x1e0fffff,
"nonce" :579883,
"InitialStakeModifier":0,
"InitialStakeModifier2":0
},
"initialize" : function () {}, // initialize the app (constructor) eg load the required modules, allocate memory
"start" : function () {}, //start the application eg open port, initialize protocol and connect nodes
"stop" : function () {}, //stop application eg close port and all connections
"free" : function () {}, //free resources (destructor) unload all modules and free memory
"message_handlers" :
{
//P2P message handlers
{"msg":{"cmd":"inv", function (node,inv_data) { %MyNode%->send_getdata(node,inv_data); } }}, //send get data message to the node sending the inv
{"msg":{"cmd":"block", function (node,block_data) { %MyNode%->validate_block(node,block_data); } } }, // call %MyNode% module method on the data
or implement the block validation protocol
},
//define rpc interface for the wallet
"rpc_wallet":
{
"module":"rpc_wallet",
"rpc_port":16820,
"index":"/wallet",
"page file":"wallet.html"
},
//define http api for block exporer
"block_explorer":
{
"module":"block_explorer",
"base path":"/api/",
"page file":"blocks.html"
}
}
}
To get pedantic on design pattern, the blockchain protocol technically it's already an application layer, and in fact it contain in itself 2 layer, the message layer, and the actual blockchain layer. The message layer can be seen as the transport layer, it encapsulate the message data, and it's the part that is handled by the node modue, it read packets from the network, and parse the message "transport" layer. The protocol module is there to deal with the blockchain layer data format, how block headers and transactions and other objects are represented on the network to be transmitted between two nodes. The protocol module contain template like type class to deserialize the message data from the node (transport layer), with run time type definition, in sort that the node can deserialize the message independently of protocol definition. The whole format of the blockchain layer data can be changed, and it wouldn't need to recompile the node module. The code of the node module is not on the git, but it goes like this for reading new message from the network https://github.com/iadix/purenode/blob/master/protocol_adx/protocol.c#L1370OS_API_C_FUNC(int) new_message(const struct string *data, mem_zone_ref_ptr msg)
{
mem_zone_ref_ptr key;
mem_zone_ref list = { PTR_NULL },my_list = { PTR_NULL };
mem_zone_ref payload_node = { PTR_NULL };
struct string pack_str = { PTR_NULL };
size_t cnt = 0;
size_t elSz = 0;
int ret,nc;
if (!strncmp_c(&data->str[4], "version", 7))
make_string(&pack_str, "{(\"payload\",0x0B000010) (0x02)\"proto_ver\" : 0,\"services\" : 0, \"timestamp\" : 0, (0x0B000040)\"their_addr\":\"\", (0x0B000040)\"my_addr\":\"\",\"nonce\":0,(0x0B000100)\"user_agent\":\"\", (0x02)\"last_blk\":0}");
else if (!strncmp_c(&data->str[4], "ping", 4))
make_string(&pack_str, "{(\"payload\",0x0B000010) \"nonce\":0}");
else if (!strncmp_c(&data->str[4], "pong", 4))
make_string(&pack_str, "{(\"payload\",0x0B000010) \"nonce\":0}");
ret=tree_manager_json_loadb (pack_str.str, pack_str.len, &payload_node);
free_string (&pack_str);
if (!ret)
return 0;
tree_manager_set_child_value_str(msg, "cmd" , &data->str[4]);
tree_manager_set_child_value_i32(msg, "size", (*((unsigned int *)(&data->str[16]))));
tree_manager_set_child_value_i32(msg, "sum" , *((unsigned int *)(&data->str[20])));
tree_manager_set_child_value_i32(msg, "cnt" , cnt);
tree_manager_set_child_value_i32(msg, "elSz", elSz);
tree_manager_node_add_child (msg, &payload_node);
code from the node module if (tree_manager_create_node("emitting", NODE_BITCORE_MSG, &msg))
{
new_message(get_con_lastline(node_con), &msg); // create the message type template based on the message command
tree_manager_node_add_child(node, &msg);
tree_manager_set_child_value_i32(&msg, "recv", pre_read);
tree_manager_set_child_value_i32(&msg, "done", 0);
release_zone_ref(&msg);
}
to unserialize the message based on the runtime type definition :
OS_API_C_FUNC(int) read_node_msg(mem_zone_ref_ptr node)
{
mem_zone_ref msg = { PTR_NULL };
struct con *node_con;
if (!tree_manager_get_child_value_ptr(node, NODE_HASH("p2p_con"), 0, (mem_ptr *)&node_con))return 0;
if (tree_manager_find_child_node(node, NODE_HASH("emitting"), NODE_BITCORE_MSG, &msg))
{
if (!tree_manager_get_child_value_i32(&msg, NODE_HASH("size"), &size))
size = 0;
tree_manager_get_child_value_i32(&msg, NODE_HASH("sum"), &sum);
mbedtls_sha256(get_con_lastline(node_con)->str, size, (unsigned char*)checksum1, 0);
mbedtls_sha256((unsigned char*)checksum1, 32, (unsigned char*)checksum, 0);
if (checksum[0] == sum)
{
unserialize_message(&msg, get_con_lastline(node_con)->str, PTR_NULL); //unserialize the message payload based on the template
tree_manager_set_child_value_i32(&msg, "done", 1);
queue_emitted_message(node, &msg); // add the parsed message in the node's emitted message queue
release_zone_ref(&msg);
con_consume_data(node_con, size);
}
}
and the actual message processing that should be scripted in there https://github.com/iadix/purenode/blob/master/purenode/main.c#L1419int process_node_messages(mem_zone_ref_ptr node)
{
mem_zone_ref msg_list = { PTR_NULL };
mem_zone_ref_ptr msg = PTR_NULL;
mem_zone_ref my_list = { PTR_NULL };
if (!tree_manager_find_child_node(node, NODE_HASH("emitted queue"), NODE_BITCORE_MSG_LIST, &msg_list))return 0;
for (tree_manager_get_first_child(&msg_list, &my_list, &msg); ((msg != NULL) && (msg->zone != NULL)); tree_manager_get_next_child(&my_list, &msg))
{
char cmd[16];
mem_zone_ref payload_node = { PTR_NULL };
int ret;
if (!tree_manager_get_child_value_str(msg, NODE_HASH("cmd"), cmd, 12, 16))continue;
tree_manager_find_child_node(msg, NODE_HASH("payload"), NODE_BITCORE_PAYLOAD, &payload_node);
ret = handle_message(node, cmd, &payload_node);
tree_manager_set_child_value_i32(msg, "handled", ret);
release_zone_ref(&payload_node);
}
tree_remove_child_by_member_value_dword (&msg_list, NODE_BITCORE_MSG, "handled", 1);
tree_remove_child_by_member_value_lt_dword (&msg_list, NODE_BITCORE_MSG, "recvtime", get_time_c()-100);
release_zone_ref(&msg_list);
return 1;
}
int process_nodes()
{
mem_zone_ref_ptr node = PTR_NULL;
mem_zone_ref my_list = { PTR_NULL };
for (tree_manager_get_first_child(&peer_nodes, &my_list, &node); ((node != NULL) && (node->zone != NULL)); tree_manager_get_next_child(&my_list, &node))
{
process_node_messages(node);
The node defintion in the first block of this post would replace the "coin core" module on the graph ( https://github.com/iadix/purenode/blob/master/purenode/ ), where all the coin logic take place, which is the part to check if block headers fit the difficulty, to compute the difficulty re targeting, check the proof of work or stake, check the transaction inputs, etc , but i think most of this could be wrote in high level language script, all the part about protocol consensus and which block is considered valid could be scripted with the high level node definition, scripting call to modules coded in C for the hard crypto part or list processing. I already have all the code to implement this with the C modules, and it uses the run time type definition so it should not be too hard to integrate a script system based on the node definition i posted above, and to make a parser to have running full node with parameters and protocol consensus wrote in high level language like this. The thing with data format definition become really useless, it's mostly useful if you want compile time verification, but anyway you can't have this with js, and C/C++ is still very weak for detecting problem at compile time, and it completely prevent true run time type checking. And unlike in javascript, all the key and variable definition can be sur typed with built in type identifier, with runtime type checking. So can have more design pattern than with javascript. As my framework is all based on runtime type definition, it allow for runtime type checking, and more robust design pattern than js, and it's all though from scratch to easily build a script engine on top of it. Where i want to get at with you is that regarding you want to code a new blockchain protocol , it would probably not be longer to code the script engine based on my framework with already 90% of all basic blockchain related code and javascript html5 app / rpc interface already working, than to start coding a blockchain node from scratch, and like this you can have your blockchain programmed already with the high level language that has all the property you want with pararelization, runtime tpe checking, modularity, design pattern & all. And i'm pretty sure we are after the same thing With clear language, easy to read, dynamic typing, asynch request, green threading, "hard threading" , javascript/html5 compatible, i'm sure we can get something cool. The point of doing this script engine is to facilitating programming more complex consensus to have protocol more evolved than only checking pow, and facilitate programming distributed application based on flexible definition of node who can run different modules/class exposed as rpc api. If the synthax remain compatible with json, maybe it can be used as template to generate js objects and or/ui, or use static html5 pages . And this kind of scripting could really not take too long to get started from the code i already have. And i'm sure you have plenty of experience and good idea to get to a script language like this, to define node/modules interface and global application logic. And any blockchain can be programmed with it independently of each other, the script engine should allow to easily write new consensus algorithm without having to change too much the underlying code. And as long as the module dependency chain remain ok, apps using those modules should be compatible with the two blockchain. |
|
|
|
@ladixDev, let's stop talking and instead produce some specifications.
I already have my specification Did you provide a repository link? There is the git there : https://github.com/iadix/purenodeThe high level design pattern is this : http://blog.iadix.com/web/images/wp/diag.svg  ( now there should be one more module in the bottom added next to rpc server & block explorer for the raytracing ) There are some infos on the site too http://iadix.com/ico/blogs/enI dont write a lot of documentation, as im only dev anyway, and I keep the code simple enough for that I can do without extensive documentation, I dont spend too much time into open office to write pdf The idea is to combine this https://github.com/iadix/purenode/blob/master/purenode/main.cAnd this https://github.com/iadix/purenode/blob/master/export/iadix.confWith script to have the full node definition with high level language, all the part that are relevant to define a specific coin out of block / tx parameters, and the network event handling for the p2p network . The http rpc interface bind automatically rpc method to module exported function name. And the trick with /api/method http url for block explorer. New methods can be added by adding exported function to the module. |
|
|
|
@ladixDev, let's stop talking and instead produce some specifications.
I already have my specification, and the working code that goes with it. I can already program application with it. There is already the test net with html5 wallet, block explorer, and raytracer. With the whitepapper, spec etc, I already have all this There is design pattern, modules, and js code. The thing is to develop commercial app, also need funding to get good graphician, press release, and doing buzz, and expert or skilled person in several domain. The thing for music distribution we have been on this even before blockchain existed. We got some good funding before ( ~150k $) for music distribution thing, where I developed js scriptable web streamer in ATL/XPCOM. This stuff of interface , components, hierachy of objects scripted in js, I know this quite in depth This whole problematic of js DOM and web streaming, and the economics involved with music distribution I know it very well and we have been on this board for very long time, with very competent person as well with the buisness, legal and technical aspect Blockchain based app can solve this i think. But im not so concerned about the coin value side of the equation, anyway for me currency never have value in themselves, they have value through what you can get with it. For the moment with btc you can get dollars and other cryptos, mostly, so as currency for me it has close to zero value. To bootstrap a currency with true value, need to find 2 party who are producing something and need what the other is producing. Like if you have gas producer and car producer , car producer want gas, gas producer want car, the currency help setting the reccord of who own what to who. If one of the two party end up with more money, it mean it can get more of what the other is producing. In the case the market cap of the coin is total gas + total car, because thats all you can get from it. Outside of this logic, currency can only get value because of some trading trick, ponzi, or speculation craze. Im not so concerned about value market in itself, or blockchain protocol themselves, for the moment the current protocols seem to do their job as currency infrastructure, even if decision power is becoming centralized with whales & mining farms, as long as the one in power are still wanting to keep it working as currency and way to settle exchange between 2 persons im ok with it, for the moment I dont ask more for it. And with the application logic, application data is not subjected to the validation by miners or stake holder, any app data is a priori valid for the network, node not involved with the app dont even have to see the data at all, only the block headers. The application layer data anyway escape the power of whales and miners, as it doesnt concern the coin data ( which is the thing that has real economic value), and only nodes running the modules (are part of application affiliate with a degree of verticalisation like private network) Have power on those blocks. Neither whales or miners have power of those block unless they are part of the affiliation. And most of the value is traded via transactions on other blockchain than the application blockchain anyway. The application blocks are mostly data relative to the application either it's content or internal states, app tokens, or whatever else. The logic for app block validation can be made by the app itself. My projects doesnt require the blockchain to even hold value at all, application can trade using any coin from any blockchain of which protocol can be handled by the node. Im not mainly focus on new blockchain protocol for coin or currency, and more in creating easily private networks controlled by application users, and distributed application who can use existing blockchain for payment, or who can use blockchain to have secure distributed data based on application protocol. The coin we are doing for ico for the moment it's mostly for funding, but that can be pet toy also to play trading, the more value it can get the better it is too, but outside of adding new functionalities and application for it, the whole market value I have to admit it's not my strong point, but anyway most of the value system in crypto world seems quite askew lol For me i see adding value to currency by making more things available throught it via application, and content distribution is one of the aspect, there can be other things like gaming or scientific computation who can be interesting , at the base of the idea is how you can trade computer ressources in relation with distributed data and crypto currencies, and application are still good way to add value to computer resources uses If you can help with scripting engine, or language definition, that is nice, and ill get into doing something like this soon, and I already have all the spec/design pattern for it works. Starting blockchain protocol from scratch, you need to have clear idea where you want to get at, and few months full time dedicated to code the node/wallet/explorer, even before the application api can even be though of. Im not too much into blockchain protocol design itself too much for the moment, just enough to have working client for most blockchain, and having modular distributed application on top of it. |
|
|
|
Doesnt seem really trivial to abstract the blockchain away from application layer, rather id build application as blockchain node modules, with complete access to blockchain protocol Even if you run a full node on the same server as the music server, you SHOULD NOT be interfacing it through spaghetti code. There should be a formal protocol/RPC-API barrier between the two. Anyway with js the best you can have is illusion of non spaghetti code, because it's not like js really support object polymorphism, or anything. The node.js packaging can give the impression of design pattern, but it's mostly intentional. Can always have definition of module/interface hierarchy for js ui app, but to me it just look like decoration. It's has to understand the node-> module->method pattern but that's all. Node are the http layer, module can be abstracted with a js class with rpc calls, but anything more evolved is not possible in js. As far as i know for js, all classes and functions are the same type, so it's hard to have good design pattern. The application can just rely on naming convention and assume the type from there, it's the best you can do with js. Which is how you end up using variable name as if it was the type name of a static class, but it's just variable naming convention there is no real "type class". The name correspond to an instance of unique class defined with the inline synthax, but it's not the the type name of a static class, it has no intrinsic meaning for the js engine. ( big difference for design pattern ^^). With enough semantic confusion it can look like design pattern, but the js engine cant do any real type checking of anything. JS programmers are used to this, even if I find this disturbing can give it the merit that it works and the synthax is intuitive for OO programmers, but in reality it's still very weak . It's very hard to have true multi layered pattern with js. You can only have one true layer of abstraction. If a js class method is used as call back and has to use different class depending on returned data type, hard to make in sort the second class is fully aware of the calling context, you can only be sure of the type at one level, because of lack of true explicit typing, even giving the instance of the caller class cant give it's type to the callee, the method can only assume the "this" type from the naming convention of the caller code. The synthax is cute & all but it's very easy to mess up with multi layered code. In the end it can only be close to spaghetti :p The design pattern has to be pretty flat or it will always end up messy with js. To me all class/modules need to be on the same level using the static class like variable naming convention of js. Each module interface is implemented as inline class instance with a specific global name, and modules call are made throught call to this object methods, callback being mostly hard coded into the object definition for a specific UI. Most of the time it's simpler to let application initiliaze the object-module instance with the parameters it can customize for it needs, and let the js object handle the call back internally. The js application need to have these module / class definition, and a node to connect to who host these modules, and then it can distribute the request on these node for the different interactions with the UI, using call to the named objects methods . But it's not hard to see how a better language can be thought of |
|
|
|
@ladixDev, let's stop talking and instead produce some specifications.
The specification needs the part on script language, the part on blockchain protocol, and application api, both for blockchain and non blockchain functions. |
|
|
|
You appear to be doing premature optimization, which as you know is an incorrect methodology in software design.
No no, i dont try to specially optimize for the moment, just keep performance enough for use. But for multimédia and interactive application, it need to be kept minimum optimized. The threshold of minimum useability require good code for interactive multi media app, I want to integrate vectorial computing and 3d too. And I already have gone through cycle of developpement for different part of the framework, even still not really in optimization phase. |
|
|
|
Doesnt seem really trivial to abstract the blockchain away from application layer, rather id build application as blockchain node modules, with complete access to blockchain protocol Even if you run a full node on the same server as the music server, you SHOULD NOT be interfacing it through spaghetti code. There should be a formal protocol/RPC-API barrier between the two. That is just correct software design. Let's dig into the API specifics on our new forum. Data formats should have specifications. As we dig into specifications, then we will understand each other. The node module hierarchy is not visible from ui/app side, so it mean in theory the UI can plug at any level of the node api, down to the binary data level to high level functions in other modules. Internally there is a dependency hierachy ( visual studio seem to struggle a bit with multithread compilation  ), a way to force the app api to a particular level is to only expose the module at highest level (that no other modules depend on ), but the application can have to go down to protocol level, to make block explorer for example, not sure it's good to force the abstraction layer too high, specially if different blockchain need to be handled by the application. And the ui/application doesnt necessarily have to know all the node modules hierarchy and the different level of the api, it can just pick the api from any module interface, depending on how it helps the application to do what it has to do. |
|
|
|
Most of the blockchain protocol is about transaction the UI doesnt have to know about the block emission, but lot of the blockchain protocol is about messages to advertize new block and transaction. The UI has to understand about the transaction format which is part of the blockchain protocol, as well potentially of the bitcore engine opcodes to be complete. But the UI doesnt have to know the opcodes to serialize the tx to an hash and sign it, but at least parse the input & output and the addresses involved. Doesnt seem really trivial to abstract the blockchain away from application layer, rather id build application as blockchain node modules, with complete access to blockchain protocol With default behavior and Event handling for generic node of a particular blockchain with only coins related functions, to emulate the functioning of classic full nodes without application modules, and new functions added to the api via modules and/or scripts. |
|
|
|
|
If the app has to make transaction, it has to manipulate at least addresses, and to be secure, at least also private key and transaction hash. If the app trust the node producing the tx hashes to sign, otherwise it need a way to display the tx , and compute it's hash in the UI. The tx itself can be built in the node based on its local wallet infos, and send the tx hash to the UI to sign.
But it seem hard to keep the system secure keeping the blockchain protocol out of the application layer, or it need a middle layer to manage some from of accounting that can be checked by all nodes on the network. And the app sign transaction using this format, and some middle layer turn it to a blockchain tx.
|
|
|
|
Ok, stop stroking your micropenis and get back to work. We could use a new toy to speculate on.
You want to speculate on this ? ? |
|
|
|
|
Show Posts
