books

[David Cantrell]

Given the recent discussions, would anyone like to review
"Embedding Perl in HTML with Mason" who isn't on the Naughty List?

-- 
David Cantrell|Degenerate|http://www.cantrell.org.uk/david

  For every vengeance, there is an equal and opposite revengeance.
-- Cartoon Law X

Re: Perl book for review

[Randy J. Ray]

On 2002.11.01 12:29 Paul Makepeace wrote:


> For the foreseeable future, .NET is an unfortunate reality of developing
> web services. You may choose to develop your service a cleaner, more
> more standards-friendly fashion,



In what way is .NET standards-unfriendly? The way the components
underpinning most of .NET Microsoft were submitted to ECMA and then
subsequently ratified, like, nearly a year ago? Oh, wait, that makes it
a standard, doesn't it. Presumably an author of a book on web services
would know this, or did you mean something else? And presumably you also
know that .NET has an open source implementation that has a substantial
amount of backing & developer interest? (go-mono.com)


I should know better than be drawn in by this sort of thing, particularly with 
the thinly-veiled insult ("Presumably an author of a book on web services 
would know this").

First, and foremost, the statement "more standards-friendly fashion" does not 
mean .NET is not standards compliant, or necessary standards-UNfriendly. The 
statement means you could develop your service as being MORE friendly.

I'm quite aware of Mono, and I'm familiar with which of the SOAP, WSDL and 
related specifications (and specific versions thereof) are W3C TRs, and which 
are merely endorsed by W3C. I know what .NET has done towards establishing 
standards certification for their protocols. But I also feel, from having 
dealt directly with Microsoft on the MapPoint.NET issues I've had, that 
interoperability to them means you have choice between VisualBasic or C#. 
Having watched the wire-traffic while devloping this client, I've seen that 
SOAP messages sent to .NET need to be very specific, but that the XML returned 
is very minimalist and generic. It's designed to work fine with their 
toolkits, but even acceptance of Java is minimal (the only Java examples they 
could provide were 3rd-party). Even though we only ever asked about the WSDL 
and SOAP-level elements, our choice to use a language other than VB or C# was 
generally cited as the cause of the problem.

And no use trying to bait me with the dark, dirtiness that is XML-RPC. I've 
been at odds with Dave Winer since I started writing my RPC::XML module in 
2000, including getting two phone calls at my office. During one of these, he 
*demanded* that I cease work on the module. (Though to be fair, I know a 
fellow at O'Reilly whom Dave actually called up at HOME to rant at.)

I _know_ that MS is being a better neighbor when it comes to standards than 
they used to. But .NET, standarised or not, is more difficult to develop 
against than it needs to be. And the fact that they are more sensitive to 
interoperability doesn't change the fact that they design their services and 
tools to herd people towards their development platform. No big deal there, 
it's their business model, it's how they make money. The original writer 
asked, "I don't know why anyone would want to develop for .NET", and the 
answer is that (for now) it's a part of the landscape.

Randy
--
[EMAIL PROTECTED]  http://www.rjray.org http://www.svsm.org

Any spammers auto-extracting addresses from this message will definitely want
to include [EMAIL PROTECTED] and [EMAIL PROTECTED]

Re: Perl book for review

[Dean Wilson]

- Original Message -
From: "Paul Makepeace" <[EMAIL PROTECTED]>
> In what way is .NET standards-unfriendly? The way the components
> underpinning most of .NET Microsoft were submitted to ECMA and then
> subsequently ratified, like, nearly a year ago? Oh, wait, that makes it
> a standard, doesn't it.

C# and the CLR have also been submitted to the ISO standards board.
Microsoft doesn't learn very quickly but it does learn. Add that to the new
commitment to getting VS C++ up to spec and it looks like Micorosft is
putting a lot more investiment in to standards than many other language
venders.

  Dean
--
Profanity is the one language all programmers understand
--- Anon

Re: Perl book for review

[Paul Makepeace]

On Fri, Nov 01, 2002 at 12:00:24PM -0800, Randy J. Ray wrote:
> On 2002.11.01 06:39 Alex McLintock wrote:
> 
> >Programming Perl in the .NET Environment PRENTICE-HALL
> >
> >Now Why anyone would want to use .NET is beyond me, but maybe someone 
> >would like to review it?
> 
> For the foreseeable future, .NET is an unfortunate reality of developing 
> web services. You may choose to develop your service a cleaner, more 
> standards-friendly fashion,

In what way is .NET standards-unfriendly? The way the components
underpinning most of .NET Microsoft were submitted to ECMA and then
subsequently ratified, like, nearly a year ago? Oh, wait, that makes it
a standard, doesn't it. Presumably an author of a book on web services
would know this, or did you mean something else? And presumably you also
know that .NET has an open source implementation that has a substantial
amount of backing & developer interest? (go-mono.com)

Maybe you meant use standards like XML-RPC. Oh, wait, that isn't
a standard*.

Paul

* this last para is a troll, btw.

-- 
Paul Makepeace ... http://paulm.com/

"What is bigger than a bread box? It can only be street-cleaning."
   -- http://paulm.com/toys/surrealism/

Re: Perl book for review

[Randy J. Ray]

On 2002.11.01 06:39 Alex McLintock wrote:


Programming Perl in the .NET Environment PRENTICE-HALL

Now Why anyone would want to use .NET is beyond me, but maybe someone would 
like to review it?

For the foreseeable future, .NET is an unfortunate reality of developing web 
services. You may choose to develop your service a cleaner, more 
standards-friendly fashion, but lots and lots of people will still have to 
deal with the chore of writing clients against .NET servers.

Though I ran out of room (and time) in my upcoming web services book to cover 
very much .NET detail, I've lately had to write against a .NET service 
(MapPoint), and have been taking plentiful notes about the headaches I've had 
to deal with. Someday, those notes will emerge as an article, or maybe a 
chapter in a follow-on book, if I'm lucky.

Randy
--
[EMAIL PROTECTED]  http://www.rjray.org http://www.svsm.org

Any spammers auto-extracting addresses from this message will definitely want
to include [EMAIL PROTECTED] and [EMAIL PROTECTED]

Re: [uk.jobs.offered] Unix System Administrator :: London

[catskin royale]

 --- Dave Hodgkinson <[EMAIL PROTECTED]> wrote:


and they are nice guys too :)

--
jamesh
[bash-the-troll]
> 
> 
> Bet one of you lot could do this...
> 

> ATTACHMENT part 2 message/rfc822 
> From: [EMAIL PROTECTED] (Zahoor Hussain)
> Subject: Unix System Administrator :: London
> Date: 1 Nov 2002 06:33:54 -0800


__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[uk.jobs.offered] Unix System Administrator :: London

[Dave Hodgkinson]

Bet one of you lot could do this...




--- Begin Message ---
Salary: Negotiable depending on experience
Start Date: Immediate

Object 1 are Consulting, Design and Development services company
specialising in Information Mangement based in Shoreditch, London.
Object 1 is looking for an experienced System Administrator to help
manage application infrastructures for a prestigious client base
including DfES, Dresdner Kleinwort Wasserstein and Wood Mackenzie.

Description
The candidate would require strong Unix (Linux and Solaris),
networking (firewalls, routers) skills and have exposure to Oracle
databases. The job is to provide 24/7 infrastructure management and
support and to help develop relevant software for the platform.

Applicants should have at least 2 years experience supporting 365x24x7
systems, be highly motivated and demonstrate proven technical and
interpersonal skills.

Skills/Technologies :
Operating systems, Solaris, Redhat
Webservers, Apache, Tomcat, Squid 
Application servers, JRUN, BEA Weblogic
Monitoring Software, Big Brother
Databases , Oracle, mySQL
Firewalls,
TCP/IP

Nice to have :
Configuration/Change management skills
Developing Server architecture specifications
Understanding of the services Object1 provides
 

Sent CV or application to 
[EMAIL PROTECTED]

No agents please.

--- End Message ---


-- 
Dave Hodgkinson, Wizard for Hire http://www.davehodgkinson.com
Editor-in-chief, The Highway Starhttp://www.thehighwaystar.com
   Interim Technical Director, Web Architecture Consultant for hire

Perl book for review

[Alex McLintock]

Hi Folks,

I have been offered some more computing books for review and so I am 
checking up to see who would like to review them for 
http://news.DiverseBooks.com and of course the London.pm website too. The 
only perl book is

Programming Perl in the .NET Environment PRENTICE-HALL


Now Why anyone would want to use .NET is beyond me, but maybe someone would 
like to review it?

Please get back to me in the next few hours if possible. alex at 
DiverseBooks dot com is best

I am also asking for a couple of PHP books, one on Star Office, and one on 
Blogging.

If you have had a book off me or are considering writing a review - you can 
review any book which you have read recently. Preferably one which you 
recommend rather than rubbish ones.

Thanks


Alex McLintock




Openweb Analysts Ltd, London.
Software For Complex Websites http://www.OWAL.co.uk/
Open Source Software Companies please register here 
http://www.OWAL.co.uk/oss_support/

Re: webmail

[Andy Wardley]

Greg McCarroll wrote:
> So can we look forward to user->name under Perl 6? ;-)

Nope, user.name  :-)

A

Re: [RFC] Mail::Thread

[Simon Wistow]

On Fri, Nov 01, 2002 at 11:11:15AM +, Simon Wilcox said:
> Does Mail::Box::Threads do what you want ?
> 
> http://search.cpan.org/author/MARKOV/Mail-Box-1.324/Box/Threads.pm

OOh. Yes. Funny, I searched for 'thread' on search.cpan and must have
missed this.

bad simon (me not you).

On the other hand it gave me something to do yesterday :)

Simon

-- 
   an atmosphere of PhD student 
  with a touch of alternative elitist radical

Re: [RFC] Mail::Thread

[Simon Wilcox]

On Fri, 2002-11-01 at 11:04, Simon Wistow wrote:
> I've implemented Jwz's mail threading algorithm, as described here 
> 
 [ snip gory details ]
> 
> Comments?

Does Mail::Box::Threads do what you want ?

http://search.cpan.org/author/MARKOV/Mail-Box-1.324/Box/Threads.pm

Simon.

[RFC] Mail::Thread

[Simon Wistow]

I've implemented Jwz's mail threading algorithm, as described here 

http://www.jwz.org/doc/threading.html 

which was mildy non-trivial because he describes certain steps really
badly. I couldn't find anything on CPAN that did it (there *is* a thread
function in Mail::Cclient though I'm not sure how decoupled that is
from the whole API and, of course, it's a bitch to install)

There are two problems with it.

1) It's slow. IT currently it takes seconds to sort 35 fairly threaded
mails, about 2 minutes to thread a heavily threaded mailbox with 661
mails in it and anything much bigger makes it run out of memory. This
could be fixed later either with optimisation or rewriting it in C but I
wanted a proof of concept first and also to work out my second problem
which is ...


2) I honestly can't think of a decent API.  Currently it returns a list
of Mail::Thread::Containers which is the root set (the starts of
threads) each of which contain a Mail::Thread::Message and a list of
children (all of which are Containers).

Mail::Thread::Messages contain a message_id, a list of references, and
subject.

My idea for an API was to do the sorting as it is at the moment and then
convert everything so that instead of a Container with a message and
chilren in it you have a Message which @ISA Mail::Internet but also has
a list of children and possibly a depth and maybe a pointer to a parent.

Then you'd do something like ...


my $thread = Mail::Thread->new(mbox=>'/home/simon/mail/inbox');
# could also do maildir and poss. imap and pop3

$thread->sort(\&by_data); # $a and $b will be Mail::Internet messages
$thread->calculate();

my @root_set =  $thread->root_set(); # returns it all at once

# alternatively
while (my ($msg, $depth) = $thread->next_message())  {
# do whatever
}



Comments?


-- 
   an atmosphere of PhD student 
  with a touch of alternative elitist radical

Monday Night Pint

[Greg McCarroll]

Some of us are getting together for a few ales on Monday night at
the Jerusalem Tavern, feel free to join us although I should warn
you its a tiny bar.

http://www.fancyapint.com/thepubs/pub356.htm

We'll probably be there from 6.30/7.00 onwards and will go for a
bite to eat at some stage.

Greg

-- 
Greg McCarroll http://www.mccarroll.org.uk/~gem/
   jabber:[EMAIL PROTECTED]

Re: webmail

[Paul Johnson]

Andy Wardley said:

> In Perl you have to care about the difference between $user->name() and
> $user->{ name }.  But TT hides all that from you.  I think that's the
> Right Way To Do It.  When you're doing "presentation" you shouldn't be
> worrying about different data types and other "programming" crap like
> that.  You want the name of the user and you don't (or shouldn't) care
> where it comes from or how it is calculated.  That's for the back-end
> code and data designers to worry about.

I agree that this is wrong.  In OO terms, it exposes the impementation to
the user.  It's wrong for templates, but it's also wrong for ordinary
classes.  If I decide that I want to change some part of the interface
from being a plain integer to calling a method, why should the users of
the class care.

Languages such as Eiffel have got this right, and yes Greg, Perl 6 will
too :-)

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

Re: webmail

[Greg McCarroll]

* Andy Wardley ([EMAIL PROTECTED]) wrote:
>
> There is one point I would like to make about syntax, however.  For TT 
> I deliberately chose an abstract syntax (e.g. 'user.name') rather than
> sticking with Perl syntax (e.g. $user->{ name }). 
>

So can we look forward to user->name under Perl 6? ;-)

Greg

-- 
Greg McCarroll http://www.mccarroll.org.uk/~gem/
   jabber:[EMAIL PROTECTED]

Re: webmail

[Andy Wardley]

David Cantrell wrote:
> Let me clear up a few things here.  I wrote my toy system because I had an
> itch which needed scratching.  

Great!

> The only reason I'm even bothering
> to argue about this is because of the incorrect assertions coming from
> people who really should know better that my sort of solution inevitably
> leads to spaghetti code and all the rest of the nastiness from Revelations.

Er no.  Well, not me at least.  I've said absolutely nothing about your
solution.  You clearly understand the principle of separating application
from presentation.  The fact that you're using Perl syntax code is neither
here nor there - it's what you do with it that matters.

The point I originally made was that *PHP* doesn't allow you to make this
clear distinction.  Sure you can write separate modules but they're still
embedded-in-the-HTML type and the whole flat namespace thing makes it
hard to plug separate "modules" back together.

So I stand by my point.  Using *PHP* tends to lead to a poor separation of
concerns typified by spaghetti code.

I certainly wasn't having a dig at your personal template solution.  In
fact, I think you're the only person who has mentioned it.  The rest of
us are talking about *PHP* :-)

There is one point I would like to make about syntax, however.  For TT 
I deliberately chose an abstract syntax (e.g. 'user.name') rather than
sticking with Perl syntax (e.g. $user->{ name }).  For one, I find this
simpler to read and write.  But more importantly, it allows the underlying
data types to change without requiring changes to the templates.  An 
abstraction of the implementation, if you like.

For testing purpose, you can define a hash of data which your page designers
(or you) can use to mock up the web pages.  Later on, you can replace the
use hash with an object and the same template sytax will call object methods 
instead of referencing hash items.  

In Perl you have to care about the difference between $user->name() and
$user->{ name }.  But TT hides all that from you.  I think that's the 
Right Way To Do It.  When you're doing "presentation" you shouldn't be
worrying about different data types and other "programming" crap like
that.  You want the name of the user and you don't (or shouldn't) care
where it comes from or how it is calculated.  That's for the back-end
code and data designers to worry about.

Some people think that calling object methods from a template is a no-no
because it changes flow control.  Personally I think this is nonsense.
Your example code demonstrates this point well.   What matters is how you
partition the system.  Things that deal with one thing should be in one 
place.  Things that deal with another should be in another.  The particular
language, syntax or implementation details are largely irrelevant.

That's why it's possible to write wonderfully clean, highly abstracted 
systems using embedded Perl, and dog-awful, messy, entangled systems
using TT or even HTML::Template (which claims to be so strict that you
can't do this, yeah right :-)


A

Re: webmail

[Andy Wardley]

Adrian Howard wrote:
> You might also want to take a look at YAML  -
> there's a YAML.pm already in CPAN.

YAML is something totally different.  It's (essentially) for data 
serialisation without the overhead of XML.  AML is designed for humans
to write.  More like POD than XML or YAML.

> They're alternate XML syntaxes that use indentation (Python anyone)

I'm afraid that's a non-starter with me then.  The only reason I've
never got beyond page 1 learning python.

A