Accessing uids

Maximilian Kossick maximilian.kossick at
Tue Aug 12 16:24:05 CEST 2008

On Tue, Aug 12, 2008 at 2:25 PM, Orville Bennett <illogical1 at> wrote:
> On Aug 12, 2008, at 3:21 AM, Maximilian Kossick wrote:
>> On Mon, Aug 11, 2008 at 10:02 PM, Big O <illogical1 at> wrote:
>>> On Mon, Aug 11, 2008 at 1:10 PM, Maximilian Kossick
>>> <maximilian.kossick at> wrote:
>>>> On Mon, Aug 11, 2008 at 6:57 PM, Ian Monroe <ian at> wrote:
>>>>> On Mon, Aug 11, 2008 at 11:37 AM, Jeff Mitchell
>>>>> <kde-dev at> wrote:
>>>>>> Today I was working on making playlists AFT-happy, which has been a
>>>>>> thorn since 1.4 when it was impossible, and I ran into a stumbling
>>>>>> block.
>>>>>> SqlMeta lives inside src/collection/sqlcollection.  This is built
>>>>>> separately, not a part of amaroklib.
>>>>>> I need to call the uid() method of SqlTrack, if the casting to
>>>>>> SqlTrack
>>>>>> works.  But I can't cast it, because I can't tell it about SqlMeta.
>>>>>> So I have the following options:
>>>>>> 1) Move SqlMeta into src/meta and have it be built into amaroklib.
>>>>>>  One
>>>>>> could argue that all known types of meta should live together so that
>>>>>> any part of Amarok can take advantage of specific features of
>>>>>> different
>>>>>> Meta types.  One could also argue the opposite  :-)
>>>> Yes, one could:)
>>>>>> 2) Add a uid() function into Meta::Track.  While some may argue that
>>>>>> this may not really "belong" to a track, remember that uidUrl already
>>>>>> exists, which in many cases just puts this uid into a url format, so
>>>>>> it
>>>>>> would essentially be a helper method so that one doesn't have to strip
>>>>>> the url-ness all over the place.  Most existing collections could
>>>>>> simply
>>>>>> return the same as uidUrl().
>>>>> Reading your email triggered a thought in my sleep-addled brain. Add a
>>>>> FileTrackingCapability.
>>>> Do we really need another capability?
>>>>>> 3) Restructure things in the database such that UIDs aren't what's
>>>>>> stored, but rather uidUrls are stored in the uniqueid fields.  This
>>>>>> involves a lot more foo elsewhere, but is doable, if rather awkward
>>>>>> and
>>>>>> somewhat of a waste of space.
>>>> Now we are getting somewhere. uidUrl is a unique identifier for a
>>>> track, which allows the collection that understands the uidUrl to
>>>> return the correct track if at all possible. Which is pretty much what
>>>> AFT does. Who cares about wasted space in a database these days?
>>> People on mobile devices with limited amounts of space?
>>> The correct question perhaps is "Does amarok care about people who
>>> care about wasted space in a database these days?"
>> Amarok does not run on any mobile device yet.
>> Even then, if you have a mobile device where half a megabyte of
>> diskspace (that's a back-of-the-envelope calculation for storing the
>> uidUrl of about 6-7 thousand tracks) matters: get a new mobile device
>> Max
> I was thinking of marijn's soc project when i wrote this:
> but the issue isn't a mobile device with limited space, it's one  which
> doesn't have much space left after installing kde, it's deps and amarok. and
> let's not forget there's multimedia on the device too. _IF_ amarok wants to
> target those devices (eventually) we shouldn't be making decisions that will
> require more work later on to make this happen.
> just my two (not quite worth as much anymore) cents.
> P.S. we probably should've done this on list to get input from others :-)
Right. Note to myself: if you are answering another gmail user's mail
directly to you, make sure to hit "Reply all"
Anyway, if we can install Amarok + kde + deps on a mobile device, we
really should not be concerned about a couple of kilobytes for storing
the complete uidUrl in the database. The flexibility of doing that
outweighs the pretty far fetched case of a mobile device which has
just enough space for amarok and its dependencies, but no more space
for any user data in my opinion.


More information about the Amarok-devel mailing list