Re: alive e/ken style projects?

Actually it was the unreliability that I was after :D
particularly for some things like fast moving objects, it makes no
sense to suffer protocol level retransmission for an out of date, or
out of order packet,
while something like a potential collision *must* be received

Its kind of an edge case, where I think the transparency seems to get
in the way, for the general case I totally agree though, which is why
i'd like it for the non-time sensitive 99% of the program, and retain
some control of the communications channels under the hood so to speak
for use in the other 1%

mostly the case is that the receiver is oblivious to the
unreliability, and its just happy to receive some piece of data which
is not yet stale... this in particular is what makes me desire the
ability to use the same abstraction for the different types of
communication channels.

because e.g. above the same type of object can have different
reliability requirements subject to context, but at the same time they
need to be confined, e.g. I should not be able to promise something to
someone via a reliable channel, something I can only receive via an
unreliable one.

sorry if I wasn't clear

On Thu, Oct 15, 2015 at 9:32 AM, Marc Stiegler <[email protected]> wrote:
> ah, you want to use waterken, which builds the reliability into the promises
> along with the pipelining, by retrying relentlessly until it gets a
> resolution (the app developer can easily implement a timeout if desired, but
> in general the right answer is to just let waterken do its thing). It is
> magnificent to use. One suspects at this point that we will not see anything
> comparable again in our lifetimes, sorta like KeyKos or Xanadu.
>
> --marcs
>
> On Thu, Oct 15, 2015 at 12:51 AM, Matt Rice <[email protected]> wrote:
>>
>> One of the things i've had difficulty with trying to use automagic
>> promise pipelining in is unreliable protocols and worse
>> mixed-reliability protocols like SCTP, say there is a promise whose
>> reply gets dropped, is there a need for some reliable exception
>> channel, or will generating an exception on timeout suffice, there
>> really doesn't seem to be an automagic answer afaict...
>>
>> not sure that anybody has tried this sort of thing before, unreliable
>> promises seem a bit counter intuitive, though I haven't used promise
>> pipelining very much, the impression I get is that modeling
>> unreliability makes things weird...
>>
>> On Wed, Oct 14, 2015 at 4:06 PM, Mark Miller <[email protected]> wrote:
>> > I wonder whether you are using automagical on two different sides of the
>> > abstraction boundary. In E/CapTP and Cap'n Proto, we platform builders
>> > put a
>> > lot of work into building promise pipelining into the platform. The
>> > result
>> > is that they are automagical to the users of these platforms.
>> >
>> > I know Waterken had the enabling mechanism for promise pipelining. But I
>> > don't remember if it was completed and made the default mode of
>> > operation.
>> >
>> >
>> > On Wed, Oct 14, 2015 at 5:28 PM, Marc Stiegler <[email protected]>
>> > wrote:
>> >>
>> >> pipelining promises is anything but automagical. Capper, my open source
>> >> nodejs server that uses promises and semi-transparent checkpointing and
>> >> webkeys, intended to bring some of the virtues of waterken to
>> >> javascript,
>> >> does not include pipelining for the promises. The pipelining is far
>> >> more
>> >> work to implement than are the promises themselves.
>> >>
>> >> --marcs
>> >>
>> >> On Wed, Oct 14, 2015 at 9:39 AM, Raoul Duke <[email protected]> wrote:
>> >>>
>> >>> >> they can be pipelined.  In particular, they can be pipelined over
>> >>> >> the
>> >>> >> network when invoking operations on remote objects, which means
>> >>> >> that a
>> >>> > So I would say, yes. But the Javascript community largely hasn't
>> >>> > discovered
>> >>> > it yet. :-)
>> >>>
>> >>> But "can" doesn't mean it happens automagically by the underlying
>> >>> framework. Maybe it does, but I suspect most likely it doesn't, yet?
>> >>> _______________________________________________
>> >>> cap-talk mailing list
>> >>> [email protected]
>> >>> http://www.eros-os.org/mailman/listinfo/cap-talk
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> cap-talk mailing list
>> >> [email protected]
>> >> http://www.eros-os.org/mailman/listinfo/cap-talk
>> >>
>> >
>> >
>> >
>> > --
>> > Text by me above is hereby placed in the public domain
>> >
>> >   Cheers,
>> >   --MarkM
>> >
>> > _______________________________________________
>> > cap-talk mailing list
>> > [email protected]
>> > http://www.eros-os.org/mailman/listinfo/cap-talk
>> >
>> _______________________________________________
>> cap-talk mailing list
>> [email protected]
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>