Accessing uids

[Big O]

On Mon, Aug 11, 2008 at 1:10 PM, Maximilian Kossick
<maximilian.kossick at googlemail.com> wrote:
> On Mon, Aug 11, 2008 at 6:57 PM, Ian Monroe <ian at monroe.nu> wrote:
>> On Mon, Aug 11, 2008 at 11:37 AM, Jeff Mitchell
>> <kde-dev at emailgoeshere.com> 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?"

>
> Max
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>



-- 
All your gmail are belong to us.