avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Silk == More Seda Extractions
Date Mon, 04 Feb 2002 14:12:15 GMT
Leo Sutic wrote:

> 
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Keep in mind that the terms of Source and Sink are Queue-centric,
>>not Stage centric.  Therefore we are choosing which Queue Source
>>we are pushing events onto.  The ThreadManager manages what Queue
>>Sinks to pull information from.
>>
> 
> I still do not understand the "queue-centric" view you
> are talking about. A Queue has an end where events go in,
> and an end where events go out. A Queue isa Source and a Queue
> isa Sink.


Correct.  The place where events go in is the Queue's Source (i.e.
the source to the queue).  The place where the events come out is
the Queues Sink (i.e. the sink to the queue).



> Now, if a source is something where stuff comes out, then
> the Source end of a queue is the end from which you pull
> events. It doesn't matter whether we are viewing this
> from the perspective of the Queue (which recieves items
> by having them stuffed into the Source and delivers them
> to the Sink), as the Source and Sink interfaces are exposed
> to the outside and should be named according to what they expose
> to users. Think about a door: If I put up a sign saying
> "In" on the outside of the door (the outside of the house),
> you'd reasonably well expect that this is the door you go in
> through. But in my "house-centric" view, I mean that this is
> the door where people go in (that is, a person in the house will
> go into/through that door) and you should enter the house
> through the "out" door, since from the inside, you will
> appear to come "out" of that door.
> 
> In addition, you get niceties like this (Source.java is full of them):
> 
>  SourceFullException Indicates that the sink is temporarily full.
>                                         ^^^^
> Which is guaranteed to confuse people.


I see your point.  (the JavaDocs were largely copied from sandstorm.

I can change the interface names back to the way that Matt had them.




>>>Would prefer StageManager. SilkServer is too much like "SilkServer(tm)"
>>>and does not immediately associate with what it does.
>>>
>>Names can be changed.
>>
> 
> Then please change Source <-> Sink.


Will do.  Your explanation above helped me to see why.





>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>Blocks have discrete interfaces, which represent specific units of work.
>>
> 
> If this is the difference between having a single handleEvent() method
> and having a more do-this-stuff method name such as fetchMailForUser()
> I see three cases:
> 
> 1) Synchronous calls through discrete interface. The method creates an event
> and enqueues it, then blocks until completion event is recieved or timeout.


That is the part that I don't like.   Synchronous calls that take a long time
are bad for scalability.  However, most of our blocks are fairly quick to
process events.



> 2) Async call through discrete interface. As above, but without blocking.


This would be really cool if we can define how to do it.



> 3) Async call through Stage interface. The event is taken straight into
> the Silk server.
> 
> Case 3 is for when you connect a Silk HTTP block with a Silk FileCache
> block.


That would be a common use.



> So, if we just see the block as a Stage (which it is), there shouldn't
> be any problems.
> 
> /LS


Cool, but what about case #2, how would you approach that?


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message