tag:blogger.com,1999:blog-5135517.post4733983140345614677..comments2023-11-05T03:54:44.710-08:00Comments on Making it stick.: DichotomiesPatrick Loganhttp://www.blogger.com/profile/02088461489050417591noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5135517.post-69306461291252545072007-04-18T09:31:00.000-07:002007-04-18T09:31:00.000-07:00All interprocess communication in Erlang is an unr...All interprocess communication in Erlang is an unreliable message send. Erlang supports many thousands of processes within one node, and so many more across nodes.<BR/><BR/>The syntax is essentially the same whether sending a message to a process here or there. Almost as one would tend to use objects and methods in Java or Smalltalk, one would tend to use asynchronous processes in Erlang.<BR/><BR/>Since all sends are unreliable, a system built in Erlang has to account for the inherent problems. i.e. reliability can only be made somewhat transparent and sooner or later the system must account for that.Patrick Loganhttps://www.blogger.com/profile/02088461489050417591noreply@blogger.comtag:blogger.com,1999:blog-5135517.post-53906372835984448032007-04-18T02:14:00.000-07:002007-04-18T02:14:00.000-07:00The OSGi service registry also allows you to call ...The OSGi service registry also allows you to call services which can be local or remote. However, the core of the discussion is should a call to a service handle the remoteness, or should it be oblivious of this remoteness. My blog goes indepth into this problem, I think you can make it transparent for the developer because the OSGi services are already dynamic, any errors can be modeled in these dynamics.<BR/><BR/>How does Erlang handle this problem that remote services can be present and not present?<BR/><BR/>Kind regards,<BR/><BR/> Peter KriensPeter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.com