On Fri, Feb 19, 2010 at 1:15 PM, ara.t.howard <[email protected]>
 wrote:

> > so long, and thanks for all the fish -- /me unsubscribes.
Please come back... Don't go away. I didn't mean to drive you off. I was
really trying to respond to your questions as seriously as I could. Please
accept my apologies if I get a bit cranky sometimes.

bob wyman

"You're no fun. You fell right over!" Firesign Theater...


On Fri, Feb 19, 2010 at 1:15 PM, ara.t.howard <[email protected]>wrote:

> On Fri, Feb 19, 2010 at 10:34, Bob Wyman <[email protected]> wrote:
>
> > Errr... Are you aware that Pádraic Brady, the one you wrote these words
> to,
> > has written thousands of lines of code to make it possible for PHP-based
> > PSHB implementations to be written in "just a few lines of code"? Someone
> > else (actually many people) wrote the thousands of lines of code that
> your
> > "few" lines of ruby rely on in order to provide a small, limited function
> > SMTP library. But, that's not surprising. An important part of getting
> > protocols used by people is to build the libraries that hide the
> complexity
> > and detail of protocols so that drag-and-drop coders, script-kiddies and
> > others can implement useful stuff without too much trouble. There will be
> > "simple" ruby interfaces to PSHB one day, if there isn't one already. In
> any
> > case, an LOC count for a library interface doesn't say anything useful
> about
> > the underlying system.
>
> well this is a turn for the worse...
>
> yes, i know him and i've used his code. i have over 200000 lines of
> open source code released myself (some it bundled on your current
> computer if it happens to a windows, osx, linux, or solaris) and am
> vaguely aware of things like measures of complexity.
>
> it's absolutely the case that LOC is a fair, but rough, heuristic for
> wrapping one's head around the difficulty involved in a domain.
> running my same script on ruby's soap library is quite revealing
>
>  cfp:1.8$ find soap/ -type f|xargs -n1 cat|loc
>  7943
>
> flawed and imperfect though it is - the size of libraries and the
> length of documentation detailing protocols is as valid an approach as
> any for guestimating complexity.
>
> ref:  http://rubyforge.org and
> http://rubyforge.org/projects/codeforpeople/
>
>
>
> > No. It takes thousands of lines of code to provide TLS support. The mere
> > fact that you need not be aware of that code is irrelevant. Any useful
> > protocol or capability will eventually be wrapped in a simple library
> > interface allowing it to be used with minimal understanding on the part
> of
> > casual coders. The fact that SMTP and TLS have already had such wrappers
> > written speaks only to their age, not to whether they are the best
> protocols
> > to handle any particular problem.
>
>
> sigh.
>
> well i'll duck out now.  for the record brett invited me to the list
> to ask this question:
>
> ---
> from    Brett Slatkin <[email protected]>
> sender-time     Sent at 18:50 (UTC). Current time there: 6:01 PM. ✆
> date    Thu, Feb 18, 2010 at 18:50
> subject Re: i'm still waiting for someone to expain to me how
> pubsubhubbub is superior mailing
>
> Hey Ara, I think this is a great question that we should discuss it in
> our public forum so we can answer the question for everyone else who
> may wonder this too. Mind posting something there?
> http://groups.google.com/group... Thanks
>
>
> and i'm wishing i hadn't, despite the fact that i learned a little bit.
>
> hopefully this thread will serve posterity well when people like me go
> looking for answers...
>
> to anyone interested: http://code.google.com/p/pubsubhubbub/  could
> really use a page or two detailing the answers to these questions
> indicated in this thread.  the 'ComaringProtocols' page makes too few
> comparisons now and, since questions like these obviously make people
> angry (oddly), some documentation might settle everyone down.
>
> also, the culture of open source projects is absolutely as important
> to their adoption as the actual technology - including tolerating
> newbs on mailing lists.
>
> so long, and thanks for all the fish -- /me unsubscribes.
>
> -a
> --
> be kind whenever possible... it is always possible - h.h. the 14th dalai
> lama
>

Reply via email to