From tristil at gmail.com  Tue Mar  4 23:19:26 2008
From: tristil at gmail.com (Joseph Method)
Date: Tue, 4 Mar 2008 23:19:26 -0500
Subject: [Alexandria-list] 0.6.4 plans
Message-ID: <167b6aa00803042019p58c2d167k9b5c85ceeb8f9779@mail.gmail.com>

Hi all,

Let's discuss what should happen for a successful 0.6.4 release. I would say:

* Optional sqlite backend (possibly using datamapper http://datamapper.org)
* Refactored library access layer (related to sqlite backend)
* librarything syncing.

We should also make a list of bugs that absolutely have to be fixed.

-- 
-J. Method

From cathal.alexandria at gnostai.org  Wed Mar  5 08:32:10 2008
From: cathal.alexandria at gnostai.org (Cathal Mc Ginley)
Date: Wed, 5 Mar 2008 13:32:10 +0000
Subject: [Alexandria-list] 0.6.4 plans
In-Reply-To: <167b6aa00803042019p58c2d167k9b5c85ceeb8f9779@mail.gmail.com>
References: <167b6aa00803042019p58c2d167k9b5c85ceeb8f9779@mail.gmail.com>
Message-ID: <20080305133210.4face131@matilda>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 4 Mar 2008 23:19:26 -0500
"Joseph Method" <tristil at gmail.com> wrote:

> Hi all,
> 
> Let's discuss what should happen for a successful 0.6.4 release. I
> would say:
> 
> * Optional sqlite backend (possibly using datamapper
> http://datamapper.org)
> * Refactored library access layer (related to sqlite backend)

I think that if you want to change how the data can be stored, that
merits a minor version number increment at least, to the 0.7 series.
It's major new functionality, marks a radical departure from how the
current system works, and requires new dependencies.

However, I would suggest that before we start storing book and library
data in any kind of database, we should consider what data we need to
store. Otherwise, the upgrade path through subsequent database versions
might get a bit messy.

There doesn't seem to be much interest in actually engaging in any
up-front design here, even though there are many and varied new
requirements and suggested features being put forward and the current
software cannot support the complexity. I just don't think that the
project can succeed by progressing only at the implementation level.
(For example, suggesting we implement the database with 'sqlite' and
'datamapper' rather than suggesting that Data Analysis on Alexandria's
domain of book metadata is required.) To be honest, it's a bit
discouraging for me, since "the upcoming redesign" is my major area of
interest.

Perhaps it would be possible to continue the day-to-day,
implementation-level development on the SVN trunk while I create a sort
of wildly experimental branch in which I could rebuild the domain model
from scratch. Kind of like an internal project fork. It'd certainly
reduce the risk of a major redesign effort, as well as providing a bit
more job satisfaction for me!

   -   Cathal Magus.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE

iD8DBQFHzqDkfMAUnRdb+8oRAoCuAJ9HxP6eQtzn5+GchTj4ddpKdg/isgCfQB8F
XNJZvmxxvbLgauRzJxPnvvk=
=kbvX
-----END PGP SIGNATURE-----

From timothy.malone at gmail.com  Wed Mar  5 09:25:08 2008
From: timothy.malone at gmail.com (Timothy Malone)
Date: Wed, 05 Mar 2008 09:25:08 -0500
Subject: [Alexandria-list] 0.6.4 plans
In-Reply-To: <20080305133210.4face131@matilda>
References: <167b6aa00803042019p58c2d167k9b5c85ceeb8f9779@mail.gmail.com>
	<20080305133210.4face131@matilda>
Message-ID: <1204727109.7002.7.camel@timdesktop>

I agree that a new backend would seem to require a bump to at least 0.7.
My vote would be to keep maintaining 0.6.3, and start on a bigger
revision to be released as 0.7. Cathal is right that a good place to
start is figuring out what data needs to be stored. Perhaps a wiki page
would be good? At the very least I think we need to start storing how
many pages a book has, and allow the user to put more detailed edition
and printing notes (like which printing of which edition a book is).
I was also thinking a new tag system would be nice. Perhaps one that
resembles the tagged bookmarks in epiphany, something with
auto-completion or a drop down list.

Tim

On Wed, 2008-03-05 at 13:32 +0000, Cathal Mc Ginley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tue, 4 Mar 2008 23:19:26 -0500
> "Joseph Method" <tristil at gmail.com> wrote:
> 
> > Hi all,
> > 
> > Let's discuss what should happen for a successful 0.6.4 release. I
> > would say:
> > 
> > * Optional sqlite backend (possibly using datamapper
> > http://datamapper.org)
> > * Refactored library access layer (related to sqlite backend)
> 
> I think that if you want to change how the data can be stored, that
> merits a minor version number increment at least, to the 0.7 series.
> It's major new functionality, marks a radical departure from how the
> current system works, and requires new dependencies.
> 
> However, I would suggest that before we start storing book and library
> data in any kind of database, we should consider what data we need to
> store. Otherwise, the upgrade path through subsequent database versions
> might get a bit messy.
> 
> There doesn't seem to be much interest in actually engaging in any
> up-front design here, even though there are many and varied new
> requirements and suggested features being put forward and the current
> software cannot support the complexity. I just don't think that the
> project can succeed by progressing only at the implementation level.
> (For example, suggesting we implement the database with 'sqlite' and
> 'datamapper' rather than suggesting that Data Analysis on Alexandria's
> domain of book metadata is required.) To be honest, it's a bit
> discouraging for me, since "the upcoming redesign" is my major area of
> interest.
> 
> Perhaps it would be possible to continue the day-to-day,
> implementation-level development on the SVN trunk while I create a sort
> of wildly experimental branch in which I could rebuild the domain model
> from scratch. Kind of like an internal project fork. It'd certainly
> reduce the risk of a major redesign effort, as well as providing a bit
> more job satisfaction for me!
> 
>    -   Cathal Magus.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE
> 
> iD8DBQFHzqDkfMAUnRdb+8oRAoCuAJ9HxP6eQtzn5+GchTj4ddpKdg/isgCfQB8F
> XNJZvmxxvbLgauRzJxPnvvk=
> =kbvX
> -----END PGP SIGNATURE-----
> _______________________________________________
> Alexandria-list mailing list
> Alexandria-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/alexandria-list


From tristil at gmail.com  Wed Mar  5 10:24:13 2008
From: tristil at gmail.com (Joseph Method)
Date: Wed, 5 Mar 2008 10:24:13 -0500
Subject: [Alexandria-list] 0.6.4 plans
In-Reply-To: <20080305133210.4face131@matilda>
References: <167b6aa00803042019p58c2d167k9b5c85ceeb8f9779@mail.gmail.com>
	<20080305133210.4face131@matilda>
Message-ID: <167b6aa00803050724id5e92fbo4e81cf6e867505de@mail.gmail.com>

>  I just don't think that the project can succeed by progressing only at the implementation level.

I agree up to a point. I _know_ that the project won't succeed if it
only proceeds at the planning level :). But seriously, I tend to focus
on incremental improvement because that seems to work with the amount
of help available to the project.

>  Perhaps it would be possible to continue the day-to-day,
>  implementation-level development on the SVN trunk while I create a sort
>  of wildly experimental branch in which I could rebuild the domain model
>  from scratch. Kind of like an internal project fork. It'd certainly
>  reduce the risk of a major redesign effort, as well as providing a bit
>  more job satisfaction for me!

Seems like a good idea to me. A couple caveats/suggestions:

* In the Python world (for example with Plone), they tend to do a
branch for each experimental feature associated with a blueprint
(called a PLIP for some reason). So there would be one branch for
sqlite-backend and another for revised-tagging-system instead of one
big branch called assorted-new-stuff
* It would be important to periodically sync trunk to the branch, to
make possible the eventual merge into trunk.
* I think we might have a philosophical difference regarding
dependencies. I think it's important to avoid re-designing and
re-implementing where there's already a good "solution" available.
That's why I would base any relational database access layer on an ORM
(not necessarily DataMapper) instead of writing a new one. It wouldn't
be a tragedy if we ended up with a new one, but it would just be
something else to maintain and comprehend.
-- 
-J. Method

From tristil at gmail.com  Wed Mar  5 10:28:06 2008
From: tristil at gmail.com (Joseph Method)
Date: Wed, 5 Mar 2008 10:28:06 -0500
Subject: [Alexandria-list] 0.6.4 plans
In-Reply-To: <1204727109.7002.7.camel@timdesktop>
References: <167b6aa00803042019p58c2d167k9b5c85ceeb8f9779@mail.gmail.com>
	<20080305133210.4face131@matilda> <1204727109.7002.7.camel@timdesktop>
Message-ID: <167b6aa00803050728w11f95e5ah645b4fd2018625a0@mail.gmail.com>

Re: a wiki page, check out http://wiki.alexandria-projects.org/wiki/Requirements

On Wed, Mar 5, 2008 at 9:25 AM, Timothy Malone <timothy.malone at gmail.com> wrote:
> I agree that a new backend would seem to require a bump to at least 0.7.
>  My vote would be to keep maintaining 0.6.3, and start on a bigger
>  revision to be released as 0.7. Cathal is right that a good place to
>  start is figuring out what data needs to be stored. Perhaps a wiki page
>  would be good? At the very least I think we need to start storing how
>  many pages a book has, and allow the user to put more detailed edition
>  and printing notes (like which printing of which edition a book is).
>  I was also thinking a new tag system would be nice. Perhaps one that
>  resembles the tagged bookmarks in epiphany, something with
>  auto-completion or a drop down list.
>
>  Tim
>
>
>
>  On Wed, 2008-03-05 at 13:32 +0000, Cathal Mc Ginley wrote:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  >
>  > On Tue, 4 Mar 2008 23:19:26 -0500
>  > "Joseph Method" <tristil at gmail.com> wrote:
>  >
>  > > Hi all,
>  > >
>  > > Let's discuss what should happen for a successful 0.6.4 release. I
>  > > would say:
>  > >
>  > > * Optional sqlite backend (possibly using datamapper
>  > > http://datamapper.org)
>  > > * Refactored library access layer (related to sqlite backend)
>  >
>  > I think that if you want to change how the data can be stored, that
>  > merits a minor version number increment at least, to the 0.7 series.
>  > It's major new functionality, marks a radical departure from how the
>  > current system works, and requires new dependencies.
>  >
>  > However, I would suggest that before we start storing book and library
>  > data in any kind of database, we should consider what data we need to
>  > store. Otherwise, the upgrade path through subsequent database versions
>  > might get a bit messy.
>  >
>  > There doesn't seem to be much interest in actually engaging in any
>  > up-front design here, even though there are many and varied new
>  > requirements and suggested features being put forward and the current
>  > software cannot support the complexity. I just don't think that the
>  > project can succeed by progressing only at the implementation level.
>  > (For example, suggesting we implement the database with 'sqlite' and
>  > 'datamapper' rather than suggesting that Data Analysis on Alexandria's
>  > domain of book metadata is required.) To be honest, it's a bit
>  > discouraging for me, since "the upcoming redesign" is my major area of
>  > interest.
>  >
>  > Perhaps it would be possible to continue the day-to-day,
>  > implementation-level development on the SVN trunk while I create a sort
>  > of wildly experimental branch in which I could rebuild the domain model
>  > from scratch. Kind of like an internal project fork. It'd certainly
>  > reduce the risk of a major redesign effort, as well as providing a bit
>  > more job satisfaction for me!
>  >
>  >    -   Cathal Magus.
>  > -----BEGIN PGP SIGNATURE-----
>  > Version: GnuPG v1.4.2.2 (GNU/Linux)
>  > Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE
>  >
>  > iD8DBQFHzqDkfMAUnRdb+8oRAoCuAJ9HxP6eQtzn5+GchTj4ddpKdg/isgCfQB8F
>  > XNJZvmxxvbLgauRzJxPnvvk=
>  > =kbvX
>  > -----END PGP SIGNATURE-----
>  > _______________________________________________
>  > Alexandria-list mailing list
>  > Alexandria-list at rubyforge.org
>  > http://rubyforge.org/mailman/listinfo/alexandria-list
>
>  _______________________________________________
>  Alexandria-list mailing list
>  Alexandria-list at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/alexandria-list
>



-- 
-J. Method

From timothy.malone at gmail.com  Wed Mar  5 12:59:13 2008
From: timothy.malone at gmail.com (Timothy Malone)
Date: Wed, 05 Mar 2008 12:59:13 -0500
Subject: [Alexandria-list] GoodReads again
Message-ID: <1204739953.7002.24.camel@timdesktop>

I committed support for importing GoodReads CSV files. Everything works
in my testing, but I'm sure that somebody will quickly find some flaws.
If anybody else uses Goodreads I'd be interested to hear about your
experiences with my importer. On my system it is a little slow but I
think that comes from my internet connection and the retrieval of data
from Amazon. I'm going to look into the amazon library some more and see
if there is a way to just fetch the cover and not bother with the other
data (which should be in the CSV file anyway).

Ratings are preserved, reviews are stored as notes, bookshelves are
stored as tags.
I can send a sample CSV file if anybody wants to try it out without
setting up an account.

Oh, and I noticed as I was importing a CSV file with over 100 books in
it, there doesn't seem to be a way to abort an import. 

Also, has anybody thought anymore about syncing support? I wrote a
preliminary RSS parser for the GoodReads feeds but I'm thinking a new
branch of alexandria is going to have to be created because it will
require some major UI changes. My thought was that they should act like
a smart library. We'll need a UI to let the user put in their username
(user number for GoodReads) and the shelf they want to access.

Tim


From ophidian at ophidian.homeip.net  Wed Mar  5 12:33:56 2008
From: ophidian at ophidian.homeip.net (Aaron Clark)
Date: Wed, 05 Mar 2008 12:33:56 -0500
Subject: [Alexandria-list] 0.6.4 plans
In-Reply-To: <20080305133210.4face131@matilda>
References: <167b6aa00803042019p58c2d167k9b5c85ceeb8f9779@mail.gmail.com>
	<20080305133210.4face131@matilda>
Message-ID: <47CED984.7090500@ophidian.homeip.net>

Cathal Mc Ginley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tue, 4 Mar 2008 23:19:26 -0500
> "Joseph Method" <tristil at gmail.com> wrote:
> 
>> Hi all,
>>
>> Let's discuss what should happen for a successful 0.6.4 release. I
>> would say:
>>
>> * Optional sqlite backend (possibly using datamapper
>> http://datamapper.org)
>> * Refactored library access layer (related to sqlite backend)
> 
> I think that if you want to change how the data can be stored, that
> merits a minor version number increment at least, to the 0.7 series.
> It's major new functionality, marks a radical departure from how the
> current system works, and requires new dependencies.
> 
> However, I would suggest that before we start storing book and library
> data in any kind of database, we should consider what data we need to
> store. Otherwise, the upgrade path through subsequent database versions
> might get a bit messy.

Did we ever get around to any actual profiling to determine WHY large 
libraries are slow?  IIRC, that was the initial impetus behind the idea 
of adding a sqlite-based backend.

Aaron

From unapersson at linuxmail.org  Wed Mar  5 13:08:31 2008
From: unapersson at linuxmail.org (Ian Davey)
Date: Wed, 05 Mar 2008 18:08:31 +0000
Subject: [Alexandria-list] 0.6.4 plans
In-Reply-To: <47CED984.7090500@ophidian.homeip.net>
References: <167b6aa00803042019p58c2d167k9b5c85ceeb8f9779@mail.gmail.com>	<20080305133210.4face131@matilda>
	<47CED984.7090500@ophidian.homeip.net>
Message-ID: <47CEE19F.6050501@linuxmail.org>

Aaron Clark wrote:

> Did we ever get around to any actual profiling to determine WHY large 
> libraries are slow?  IIRC, that was the initial impetus behind the idea 
> of adding a sqlite-based backend.

When I looked at it a long time ago, the problem was not the backend, 
but rather loading then resizing all the cover images to thumbnail size. 
They'll all stored on disk at the original size then resized to fit 
depending on whether they're displayed on the thumbnail view or the 
larger size.

So one optimization would be to resize on import to the two standard 
sizes then load those from then on.

ian.

From tristil at gmail.com  Wed Mar  5 18:18:43 2008
From: tristil at gmail.com (Joseph Method)
Date: Wed, 5 Mar 2008 18:18:43 -0500
Subject: [Alexandria-list] 0.6.4 plans
In-Reply-To: <47CEE19F.6050501@linuxmail.org>
References: <167b6aa00803042019p58c2d167k9b5c85ceeb8f9779@mail.gmail.com>
	<20080305133210.4face131@matilda>
	<47CED984.7090500@ophidian.homeip.net>
	<47CEE19F.6050501@linuxmail.org>
Message-ID: <167b6aa00803051518j4101b4d2p127198c9461d7b4@mail.gmail.com>

I created a branch at
http://alexandria.rubyforge.org/svn/branches/speedup/ to experiment
with this. I already changed the strategy so that icons are loaded
from a cached file instead of being scaled. But it doesn't seem to
make that much difference.

On Wed, Mar 5, 2008 at 1:08 PM, Ian Davey <unapersson at linuxmail.org> wrote:
> Aaron Clark wrote:
>
>  > Did we ever get around to any actual profiling to determine WHY large
>  > libraries are slow?  IIRC, that was the initial impetus behind the idea
>  > of adding a sqlite-based backend.
>
>  When I looked at it a long time ago, the problem was not the backend,
>  but rather loading then resizing all the cover images to thumbnail size.
>  They'll all stored on disk at the original size then resized to fit
>  depending on whether they're displayed on the thumbnail view or the
>  larger size.
>
>  So one optimization would be to resize on import to the two standard
>  sizes then load those from then on.
>
>  ian.
>
>
> _______________________________________________
>  Alexandria-list mailing list
>  Alexandria-list at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/alexandria-list
>



-- 
-J. Method

From tristil at gmail.com  Wed Mar  5 19:16:16 2008
From: tristil at gmail.com (Joseph Method)
Date: Wed, 5 Mar 2008 19:16:16 -0500
Subject: [Alexandria-list] 0.6.4 plans
In-Reply-To: <47CF328F.4040402@linuxmail.org>
References: <167b6aa00803042019p58c2d167k9b5c85ceeb8f9779@mail.gmail.com>
	<20080305133210.4face131@matilda>
	<47CED984.7090500@ophidian.homeip.net>
	<47CEE19F.6050501@linuxmail.org>
	<167b6aa00803051518j4101b4d2p127198c9461d7b4@mail.gmail.com>
	<47CF328F.4040402@linuxmail.org>
Message-ID: <167b6aa00803051616x78dbbdcana14dcfa4f63d8ee8@mail.gmail.com>

I'm not really sure what's going on, but the old code was supposed to
load the icons from memory once it had been scaled the first time. I
don't think it really worked as advertised, but if it had worked there
would have been a noticeable difference between library loading when
Alexandria starts and when switching libraries afterwards, which I've
never seen. I think that the scaling operation and the image loading
are fast compared to some other slower operation, maybe the yaml
loading or maybe the progressive loading into the treeview. If I had
to guess right now, I'd say it's a limitation of the treeview itself,
that it's slow to write to.

On Wed, Mar 5, 2008 at 6:53 PM, Ian Davey <unapersson at linuxmail.org> wrote:
> Joseph Method wrote:
>  > I created a branch at
>  > http://alexandria.rubyforge.org/svn/branches/speedup/ to experiment
>  > with this. I already changed the strategy so that icons are loaded
>  > from a cached file instead of being scaled. But it doesn't seem to
>  > make that much difference.
>
>  Was the slowdown simply in the rendering the images then?
>
>  Do you think displaying the basic cover image for all thumbnails then
>  lazy loading the actual images would help?
>
>  ian.
>



-- 
-J. Method

From tristil at gmail.com  Wed Mar  5 20:30:56 2008
From: tristil at gmail.com (Joseph Method)
Date: Wed, 5 Mar 2008 20:30:56 -0500
Subject: [Alexandria-list] GoodReads again
In-Reply-To: <1204739953.7002.24.camel@timdesktop>
References: <1204739953.7002.24.camel@timdesktop>
Message-ID: <167b6aa00803051730g2599604sd6cb0bc6195c178c@mail.gmail.com>

Yeah, it sounds like something that could be worked out in a branch,
but it sounds very promising. Could there/should there be a common
interface for LibraryThing as well?

> Also, has anybody thought anymore about syncing support? I wrote a
> preliminary RSS parser for the GoodReads feeds but I'm thinking a new
> branch of alexandria is going to have to be created because it will
> require some major UI changes. My thought was that they should act like
> a smart library. We'll need a UI to let the user put in their username
> (user number for GoodReads) and the shelf they want to access.

> Tim
-- 
-J. Method

From cathal.alexandria at gnostai.org  Thu Mar  6 21:23:28 2008
From: cathal.alexandria at gnostai.org (Cathal Mc Ginley)
Date: Fri, 7 Mar 2008 02:23:28 +0000
Subject: [Alexandria-list] 0.6.4 plans
In-Reply-To: <167b6aa00803050724id5e92fbo4e81cf6e867505de@mail.gmail.com>
References: <167b6aa00803042019p58c2d167k9b5c85ceeb8f9779@mail.gmail.com>
	<20080305133210.4face131@matilda>
	<167b6aa00803050724id5e92fbo4e81cf6e867505de@mail.gmail.com>
Message-ID: <20080307022328.70b64cfd@matilda>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 5 Mar 2008 10:24:13 -0500
"Joseph Method" <tristil at gmail.com> wrote:

> > sort of wildly experimental branch in which I could rebuild the
> > domain model from scratch. Kind of like an internal project fork.
> 
> * In the Python world (for example with Plone), they tend to do a
> branch for each experimental feature associated with a blueprint
> (called a PLIP for some reason). So there would be one branch for
> sqlite-backend and another for revised-tagging-system instead of one
> big branch called assorted-new-stuff

This is fine for discrete changes and new features, but probably
wouldn't work for a total overhaul the way I'm thinking about it.

One note though, it might be good to create a sort of convention for
naming the branches so we don't run out of names in SVN. So branches for
the alexandria module would go into 'branches/alexandria' and their
names could be prefixed by the most recent release number. At the
moment, there's 'branches/alexandria/0.6.3-maintenance' for example. So
instead of 'branches/revised-tagging' (which doesn't have a lot of
context) we could have 'branches/alexandria/0.6.3-revised-tagging'

> * It would be important to periodically sync trunk to the branch, to
> make possible the eventual merge into trunk.

Then perhaps a branch isn't exactly what I'm looking for. I wouldn't
want to be constrained to making my changes in any way compatible with
the SVN trunk for a considerable time. Perhaps a new, experimental
application is the way to go (I might eventually create a new module in
SVN if I can think up a good name...)

In any case, I can continue to work on the analysis and design
directions I'm interested in on my journal and on the wiki. I'll
consider what to do with the code whenever I'm beyond the stage of
small prototypes.

I'm still interested in maintaining the current system, fixing bugs,
adding features (and coordinating the translation team). 

> * I think we might have a philosophical difference regarding
> dependencies. I think it's important to avoid re-designing and
> re-implementing where there's already a good "solution" available.
> That's why I would base any relational database access layer on an ORM
> (not necessarily DataMapper) instead of writing a new one. It wouldn't
> be a tragedy if we ended up with a new one, but it would just be
> something else to maintain and comprehend.

You misunderstand my concerns. I can expand upon them in a few points:

  * I agree that we should use existing free software libraries
when it's useful, (though we should deal with the dependencies in a
disciplined way, giving maximum flexibility to the users).

  * I don't think a micro-version revision shouldn't add major new
library requirements, or major new functionality. Hence I strongly
suggest any version of Alexandria which uses a relational database
should /not/ be in the 0.6 series. Bump it to 0.7.0

  * I feel that thinking about possible software solutions should
not /start/ with considering the technical means of how they should be
accomplished; functional requirements should take precedence.


Anyway, if I can find a bit of spare time and energy I'll get into my
analysis mode in the near future (while tracking down as many of those
50 open bugs as possible too... gotta have a hobby!)

   -   C.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE

iD8DBQFH0KcpfMAUnRdb+8oRAk5aAJ9qAQ1eZBMBDCu6xDdLPufh5kdr+ACgl0sH
uqsoPyIniWJH1l9wZt4seDY=
=q6wD
-----END PGP SIGNATURE-----

From tristil at gmail.com  Thu Mar  6 23:40:56 2008
From: tristil at gmail.com (Joseph Method)
Date: Thu, 6 Mar 2008 23:40:56 -0500
Subject: [Alexandria-list] 0.6.4 plans
In-Reply-To: <20080307022328.70b64cfd@matilda>
References: <167b6aa00803042019p58c2d167k9b5c85ceeb8f9779@mail.gmail.com>
	<20080305133210.4face131@matilda>
	<167b6aa00803050724id5e92fbo4e81cf6e867505de@mail.gmail.com>
	<20080307022328.70b64cfd@matilda>
Message-ID: <167b6aa00803062040k47c61695o296d2e9cf1a8e4fb@mail.gmail.com>

>   * I don't think a micro-version revision shouldn't add major new
>  library requirements, or major new functionality. Hence I strongly
>  suggest any version of Alexandria which uses a relational database
>  should /not/ be in the 0.6 series. Bump it to 0.7.0

Agreed. I'm probably going to do a proof of concept in the speedup
branch to answer the question of whether it will make a difference,
but this might not have anything to do with the final implementation.

>   * I feel that thinking about possible software solutions should
>  not /start/ with considering the technical means of how they should be
>  accomplished; functional requirements should take precedence.

I hear you. I tend to like to play with new toys, without a view to
the actual need for them.

>  Anyway, if I can find a bit of spare time and energy I'll get into my
>  analysis mode in the near future (while tracking down as many of those
>  50 open bugs as possible too... gotta have a hobby!)

Even though it's on the wiki, it would be helpful if you'd share your
analysis on the list  as you go.
-- 
-J. Method