PDA

View Full Version : Re: Rescan



Pat Farrell
2004-04-17, 19:30
From: Dan Sully <daniel (AT) electricrain (DOT) com>
> I think you're trying to make too much happen to fast. Ideas are good.

I am not trying to make things happen, just to make discussion happen.

> * These are problems that SlimDevices and the developers are aware
> of. I thought that had been clearly communicated.

Nope, I missed that.


> * They are being worked on. However, there are other bugs/issues
> that are higher priority.

Which is the discussion that I was raising.
Rather than beat arround the bush, who is the Product Manager for
the SlimServer software? I can see that SlimDevices is paying for
engineers to work on it. Who decides what features are what priority?
where is it documented? Is there a roadmap?


>* Design cannot be rushed. Right now there are a lot of people very busy,
> and a context switch would only delay that work which also needs to be
> done.

I don't follow you here. What design is in progress? which is essentially
the same question as the roadmap above....



>I've seen you complain a few times about the lack of documentation of
>protocols and the code base. A great way to start out helping, and to further
>your own knowledge of the software would be to help out in those areas.

If you look, you'll see that my "contributions for consideration" were
documentation. And I was actively running the CVS code until the firmware
foulup. And if the firmware is ever released, I'll probably go back to testing.

>And as always with free software: "patches welcome".

I'm not even willing to execute the code until the 2x firmware settles down.
Or at least until the firmware testing allows for backwards deinstallation
when it doesn't work.

The cached database helped, as kdf's posting said. But they are only a bandaid
on the real problem. As I see it, IMHO, YMMV, etc.

Writing documentation is a traditional way to start. Probably suitable
penance for rookies. But it is not my strength. I write wonderful, structured,
object-oriented, scalable software. No one ever gets pissed off at my software.
They occasionally do at my prose.

A more fundamental problem is that system documentation, code philosophy
and other internal documentation have to be written by someone who knows
the system. Or as a minimum, they have to be carefully reviewed and vetted
by someone who fully groks the system. It is helpful to have these documents
be organic, growing with the project from a tiny seedling.

I looked at the file directory/preferences/logging code, and it quickly
falls into
the morass of multi-platform preferences. Which the Java folks pretend
that they've addressed in Java 1.4, until you try to implement it and see
all the "implementation details" left to the reader as exercises. I don't
see guidance on how religiously platform independent we need to be, or
where it is allowable to cheat in observance of reality.

I picked this because the current approach violates fundamental security
guidelines, something I get paid to worry about. But whether that is
most important or not is really the call of the Product Manager.

My interest is putting a real database into the system, and putting
a proper abstraction in so that folks who do not want a database,
for whatever reason, can continue to use whatever alternative they like.
For the record, Perl DBI is not the right level of abstraction, because it
makes the programmer care about and know that you are talking to a database.

Pat



Pat Farrell pfarrell (AT) pfarrell (DOT) com
http://www.pfarrell.com

kdf
2004-04-17, 23:42
Quoting Pat Farrell <pfarrell (AT) pfarrell (DOT) com>:


> My interest is putting a real database into the system, and putting
> a proper abstraction in so that folks who do not want a database,
> for whatever reason, can continue to use whatever alternative they like.
> For the record, Perl DBI is not the right level of abstraction, because it
> makes the programmer care about and know that you are talking to a database.
>
fyi...moodlogic integration uses Win32::OLE to access a MSAccess MDB file (I
have been working on this exact bit of code a lot this week), its not making
the grade that this discussion would seem to desire. Sadly, moodlogic also
requires that the server runs on Windows (already a lag on speed for windows).
The current speed winnder for scan is iTunes.

I've looked for ways to get at an MDB file from a pure perl perspective, but I
can't find one that doesn't require the windows machine running as an ODBC server.

-kdf