[Openinteract-dev] Re: [Poop-group] [announce] The Object Persistathon! (2nd try)

[Darren Duncan]

Simon Cozens is including a chapter on POOP in _Advanced Programming
Perl, 2nd edition_, an O'Reilly book.
As he is busy with a new direction in his life, I have agreed to
co-ordinate gathering material and code for possible inclusion in the
chapter from authors and users of POOP frameworks.
Implement classes to drive this schema (minimally remodelling as you

<snip>
<snip>
<snip>

I will reply to this using 2-3 multiple separate messages that are more
targeted. All of *those* will go to poop-***@lists.sourceforge.net.

First of all, I would *definitely* be interested in implementing the
things you mention using my bleeding-edge Rosetta/SQL::Routine framework.
This sort of thing is just the kind of exposure they need, and will
provide a good documentation opportunity to demonstrate how to do certain
common tasks, both on an objective and a comparative basis.

Unfortunately, I have started having new bad sectors appearing on my hard
disk, and will be having it replaced tomorrow under warranty. This will
take a few days, during which I probably won't have computer access
necessary to do the work. I will also need a minimum of a week after
those few days to get my implementation ready. Having 2-4 weeks is
preferred. But suffice to say that working on these modules is more or
less my full time job at the moment, so I'm putting in long hours.

So, when do you / does Simon need these implementations by, either full or
partial? Eg, when are early drafts and final drafts needed? Is the book
on a rigorous publishing schedule?

Also, do the implementations need to be able to work as is for a
long period of time, or is it okay that details may require small changes
later due to module API changes? While I'm mostly nailed down, there are
still a few pending API changes to my modules. They *are* pre-alpha.

I'll send separate replies about task list details and suggested
task additions; they will all go to poop-***@lists.sourceforge.net.

Also, if anyone is interested in my modules, I accept offers of
assistance. (Aside from replies to some RFC emails over the last 2 years,
I've been doing them entirely on my own.) I also have no list specific to
developing or using my modules yet, but may start one later when they
start to get a user base or multiple interested developers.

Thank you. -- Darren Duncan

[Simon Cozens]

Post by Darren Duncan
First of all, I would *definitely* be interested in implementing the
things you mention using my bleeding-edge Rosetta/SQL::Routine framework.

Ah. I didn't ask for that.

You see, there are about 30,000 new, cool and bleeding edge object persistence
/ object representation frameworks on CPAN, and I don't want the chapter to be
30,000 pages long. To avoid this, I had to make a selection, and the problem
with making selections is that it upsets people who wrote the things which
didn't get selected. I'm sorry about that. I tried to select a list of
frameworks which were either well known, widely used or well designed; you can
amuse yourself by guessing which category I filed each one into. The final
list was Alzabo, SPOPS, CDBI, Pixie, Class::Persist and Tangram, and I'm
afraid that's not negotiable. I have to make a selection somehow.

Implementing the stuff requested might be good for your framework anyway and
to check that it can really do all those things, but I'm afraid it won't get
it covered in the book. (although I will be naming some notable alternative
choice such as Rosetta in the last few paragraphs) Again, sorry about that,
but attempting to cover everything would be madness.

I've had to do this with templating toolkits too, and doubtless I've already
offended someone by my selection there as well.

[Dave Rolsky]

Post by Simon Cozens

Post by Darren Duncan
First of all, I would *definitely* be interested in implementing the
things you mention using my bleeding-edge Rosetta/SQL::Routine framework.

Ah. I didn't ask for that.
You see, there are about 30,000 new, cool and bleeding edge object persistence
/ object representation frameworks on CPAN, and I don't want the chapter to be
30,000 pages long. To avoid this, I had to make a selection, and the problem
with making selections is that it upsets people who wrote the things which
didn't get selected. I'm sorry about that. I tried to select a list of
frameworks which were either well known, widely used or well designed; you can
amuse yourself by guessing which category I filed each one into. The final
list was Alzabo, SPOPS, CDBI, Pixie, Class::Persist and Tangram, and I'm
afraid that's not negotiable. I have to make a selection somehow.

However, I would be happy to include this stuff in another document at
poop.sourceforge.net.


-dave

/*===========================
VegGuide.Org
Your guide to all that's veg.
===========================*/

[Darren Duncan]

Post by Simon Cozens

Post by Darren Duncan
First of all, I would *definitely* be interested in implementing the
things you mention using my bleeding-edge Rosetta/SQL::Routine framework.

Ah. I didn't ask for that.
You see, there are about 30,000 new, cool and bleeding edge object persistence
/ object representation frameworks on CPAN, and I don't want the chapter to be
30,000 pages long. To avoid this, I had to make a selection, and the problem
with making selections is that it upsets people who wrote the things which
didn't get selected. I'm sorry about that. I tried to select a list of
frameworks which were either well known, widely used or well designed; you can
amuse yourself by guessing which category I filed each one into. The final
list was Alzabo, SPOPS, CDBI, Pixie, Class::Persist and Tangram, and I'm
afraid that's not negotiable. I have to make a selection somehow.

Thanks for clearing that up now.

The original posting gave no indication that there was a "final list". It
simply said that all people who want to submit for a framework can do so.
In fact, the closest thing to any list was giving a few examples and
saying who was doing some and which needed help. No indication that was
it. If I am wrong about this, then please say where the list was first
announced, as I missed that context.

I appreciate you being as up front with this as early as you are. Now I
won't have to waste my time implementing all those specs and tests etc.

On the other hand, I will continue to give feedback and suggestions on the
given schema and other things that the approved frameworks need to
implement.

Post by Simon Cozens
Implementing the stuff requested might be good for your framework anyway and
to check that it can really do all those things, but I'm afraid it won't get
it covered in the book. (although I will be naming some notable alternative
choice such as Rosetta in the last few paragraphs) Again, sorry about that,
but attempting to cover everything would be madness.

I quite understand. And good luck to you on the book project.

Even a mention in the printed book is very much appreciated. Please let
me know if there is anything about it you don't understand, so to make
sure that any mention of it is factual.

I look forward to a 3rd edition of the advanced perl book, by which time
Rosetta et al should be relatively mature and well known.

Post by Simon Cozens
I've had to do this with templating toolkits too, and doubtless I've already
offended someone by my selection there as well.

Well, this is a limit of a printed book.

Perhaps you could mention in the book that an expanded version of those
chapters is available on the O'reilly website, and anyone who missed out
getting in the book can have equivalent info there in the electronic
appendicies.

-- Darren Duncan

[David Nicol]

On Tue, 30 Nov 2004 00:14:56 -0800 (PST), Darren Duncan

Post by Darren Duncan
I appreciate you being as up front with this as early as you are. Now I
won't have to waste my time implementing all those specs and tests etc.

Me too.

On yet another hand, having a standard problem to solve in yer examples
would make picking and choosing from the multitude easier, when you have
to select a persistence abstraction, from looking at the documentation of them
all.