On 14/02/2008, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
> On Thu, 14 Feb 2008 19:19:33 +0100, Igor Stasenko wrote:
>
>  ...
>
> > What can i say? Only that you are real guru in metaprogramming, and
>  > i'm lacking in expertise to deal with this task.
>
>
> Thank you, but that's too much for this grey-bearded OM :) Don't forget,
>  you made Hydra going :)
>
>
>  > I never got so deep under the hood to have need in creating a block
>  > contexts, or using #ifCurtailed: methods.
>
>
> #ifCurtailed: is only needed if you cannot do ([]ensure: []), etc, for
>  whatever reason, with HydraSMS. Will try to avoid them if (if!) possible.
>
>  ...
Yes, i read a comments in this method before, and it was exactly
that you just wrote: avoid at all costs :)
>
>
>  > Maybe it would be less confusing for me, from a start, if methods
>  > names would be #remotelyDo: , #locallyDo:..
>
>
> Now in Huston there's a problem: both #atHomeDo: and #atWorkDo: never
>  result in #locallyDo: ...
>
>
>  > I'm working at home, about a 2 years till now, so there is no real
>  > difference for me between #atHomeDo: and #atWorkDo: :)
>
>
> LOL :)
>
>
>  > In general, i finally understood your idea. But due to my lack of
>  > practice (and knowledge) in uber-metaprogramming i don't think i will
>  > be capable do that without help :)
>
>
> We can find a meeting point somewhere between us, I'm sure we can :) You
>  know why? it's Smalltalk :)

No problem, but it needs a time to learn everything (to be precise -
infinite time) :)

>
>
>  > What i can currently do, is provide an implementation of reliable
>  > bidirectional communication. The rest, i hope you can do yourself.
>
>
> If I had a wish free: when you begin with reliable bidirectional
>  communication please use, for the public part, the vocabulary which is
>  present in Socket's message categories #open, #queries, #receiving,
>  #sending and #waiting. Please.
>
channels don't having too much methods requiring that many category types.
As you may noticed they are very basic wrap around corresponding primitives.

>  See, SocketStream is a user of Socket, so G"oran would have a wonderful
>  SocketStream work-free weekend :-D
>
>
>  > Orr.. if you prototype most of meta-crunching stuff and point me out
>  > what places i should add to make it live.
>
>
> I will meet you there, could start by populating subclasses which extend
>  your Hydra channel classes, like
>
>   SocketLikeHydraReceivingChannel
>   SocketLikeHydraSendingChannel
>
>  and then we can see how far this gets us up to a meeting point :)
>

You can't have two kinds of 'SocketLike' channels.
If you talking about stream sockets, which is reliable kind of
communication - they are bidirectional by default. So, there can be
only a single class 'SocketLikeHydraChannel'.

If you talking about UDP, or raw sockets, then channels is already
providing comparable functionality (and a little on top).
But there are differencies, that why i chosen (maybe inconvenient)
names of methods.
The intent was to indicate that it's not a sockets (to not put you in
false direction that you can operate with channels as with sockets).
Also, note that is not really a final design, just a preview (message
names and even primitives can be changed, and it's a low-level layer,
so what the deal) :)
It will need some time to clean things a bit and make it look like a
real API for public use.

>
>  /Klaus
>
>
>  P.S. please now switch to offline email, unless you don't fear that we get
>  moderated :)
>



-- 
Best regards,
Igor Stasenko AKA sig.