On Sun, 6 Dec 2009 21:45:36 +0300 Dmitry Balakshin <[email protected]> wrote:
> Hello! hi > > On Tue, Dec 01, 2009 at 10:44:56PM +0200, Alfeiks Kaanoken wrote: > > Hi all, > > I want to present two solutions for rpc interface generation/rpc > > support: > > I. RPC box abstraction - it's a new layer above IPC box (I will > > introduce ipc box later here). > ... > > II. Pure IDL - it's a method to describe all interfaces via sdl > > (scheme-like - it's partially made) for example: > > I think IDL solution is more suitable right now. It will cut some of the > hand written code, making it less error prone. It also aims to higher > performance, which I think is important for us at current stage of > development. The problem is that the system is really distributed (vfs, fses, system bus and so on), it's not so trivially to design complete language for IDL. I think that IDL should has a basics system concepts i.e. it must know what to generate on vfs, fs, block, event subsystems , or not - it's a good question of a rpc design. > We need to design agile and simple language here, or borrow already existent > solution, perhaps. Actually there are no problem to make it works, there are a problem what to do, not how to made. Current design is very ugly ;( > > RPC box method looks more flexible and resembles printf() style programming > (this is a plus, imho). But I don't think we need it right now. By the way, this design solve problem with the distributed system, just set a public headers - and all other things is a developer headache i.e. where it will be located and how it will handled. I will try issue with IDL design, but I think that there are several mixed solution possible... Methodically remote procedure call is better for simple client-server methodology, but in the system we has a more complex set of this. We have a translator, end point and so on - I think that it's better to determine abstractions and terminology first. There is a problem with resource resolving - and this is a protocol issue, to develop IDL I need to know all this issues to design the flexible one. > > Best regards, > Balakshin. > _______________________________________________ > Jarios-dev mailing list > [email protected] > http://lists.jarios.org/cgi-bin/mailman/listinfo/jarios-dev -- Alfeiks Kaänoken, Team Lead of the Jari OS R&D Team. http://jarios.org Free open-source microkernel-based multiservice RTOS
pgp90czvxsZF7.pgp
Description: PGP signature
_______________________________________________ Jarios-dev mailing list [email protected] http://lists.jarios.org/cgi-bin/mailman/listinfo/jarios-dev
