User talk:KingIR

From TrillWiki

Contents 1 nowPlaying API 2 Random Comments 3 TrillyTunes 4 Skinning information

[edit] nowPlaying API

• I had a suggestion on the nowPlaying API, btw. Feel free to ignore as you choose. :)
  In addition to the enumeration of the playlist et al, might it make sense to do a 'nowPlayingCurrent' (which would return just the presently-playing song), and a 'nowPlayingPlay' (which would let you play one of the songs in the playlist, or even play an arbitrary media file)? In particular, that one could be neat since you could then have things like, when a specific action in a plugin occurred, use the nowPlaying functionality to play a specific user-selected MP3 file or whatever. :) -- Sparks 06:34, 11 Dec 2005 (CST)

• Well, it actually was eh?one who created the nowPlaying API -- I would have done it a lot more simple ;-) Frankly, I even do not understand everything he describes there :-O
  Anyway, I would create another API, like... musicPlay or something with functions such as musicPlayPlayFromPlaylist, musicPlayPlayFromFile, musicPlayAddToPlaylist, musicPlayPlaylistEnumerate and so on. And concerning nowPlayingCurrent: isn't that exactly what the nowPlaying API is for atm? *confused* -- KingIR 17:26, 11 Dec 2005 (CET)

• As I read it, the nowPlaying stuff lets you enumerate the playlist (I.e. all the songs there), and lets you register to receive a callback (which doesn't appear to be documented) when the song changes. I meant a way to just request 'what's the current song,' without waiting for a change. But you're right that it's not the world's clearest API; I'm not entirely certain I have that right. -- Sparks 13:23, 11 Dec 2005 (CST)

• The proposal only covers the registration and management of plugins that implement the API. the rest is still stuck up in my head (playlist enumeration & manipulation, datatypes, file time, resolution, metadata, performing actions such as pause). The main reason for the complicated design of the api is this line quoted from pluginRegisterAPI: "Only one plugin may be registered for a particular API at the same time. Be sure to unregister when the plugin stops." only one plugin can register for an api at a time :s I've since realized realized that it's probably a lot easier to have all plugins register for an arbitrary external api (a good standard might be to make the event = guid) and have plugins that need to enumerate nowPlaying plugins send a nowPlayingImplemented to each plugin returned by pluginExternalEnumerateAPI to see which ones implement the spec. Since most of this is purely theoretical at this point, the api documentation will of course yield to the first implementation/public opinion :) feel free to delete/modify pages as you please, in the meantime I'll document more of my ideas and some of the stuff i've already implemented in an upcoming version of one of my plugins :D -- Eh?one 21:58, 11 Dec 2005 (CST)

• Aah this makes everything a lot clearer. I was confused as "nowPlaying" sounds like "what is playing at the moment?", but now I see your ideas go further. Anyway, I think there's a reason why only one plugin can provide an API at a time. I mean, why should anyone have two or more media player plugins running? Well, however, I'm willing to go this way too. :-) But what's your last sentence? Your creating a media player plugin, too? -- KingIR 17:28, 12 Dec 2005 (CET)

• As much as I can understand where you're coming from on this, eh?one, I think you'd do better to skip the whole 'register' and 'unregister' thing. Developers are expecting to be able to request the 'nowPlaying' API and get back a plugin implementing it. If they get back multiple ones... how do they react? How should they work with it? Etc. I think it's the responsibility of the plugin to have a "do not answer _nowPlaying_ calls from other plugins" if it's possible something else running simultaneously is supporting it; a plugin requesting an API should not have to pick between multiple implementations, as the whole point of the API thing is that a plugin just says 'I want this' and whatever implements it, provides it. (Though really, I'm with KingIR in terms of, why would anyone have two or more media players running?) :) -- Sparks 13:10, 12 Dec 2005 (CST)

• Alright, scratch the whole registering idea then; for media players it seems more trouble than it's worth. It unnecessarily complicates the entire thing... Afterall, we do want devs to actually be able to implement the specification :)
• As for why people would have more than one player running: Lets take me for example. Winamp is my primary player (because of the amazing database capabilities & ipod/file format support), but I also use TrillyTunes for those times I just want to do some light listening. I also run Media Player Classic when I'm watching TV shows or movies I've captured. Occaisonally I play DVD's with PowerDVD. As you can see, I use a lot of different media players, perhaps too many lol.
• Media players are only the beginning though. For example, UFS' next version will actually be divided into an HTTP server and the actual File Sharing interface/management portions (both internally in the same plugin tho). Other plugins will be able to use the server API that the web server implements to serve up http, XMPHTTP, soap, etc and the file sharing portion will be able to share files via http, ftp, https or whatever other protocols people decide to code. Obviously, Trillian should be able to have more than one plugin implement the server api, but as thing stand right now there is no sound way to do this. Anyway, I do have a few tricks up my sleeve and I will be releasing both the specification documentation and the reference implementation on the wiki (can we upload files around here?). Hopefully it'll be both easy to use and implement (relatively). If you guys have any ideas I'd like to hear them :)

-- Eh?one 19:05, 12 Dec 2005 (CST)

• First of all, I think we need a 'design' page so poor KingIR's page isn't being cluttered. Second? If a plugin is implementing a generic API that other plugins might implement, I would argue that it is the plugin's responsibility to see if something else has registered that API. If something else has, it simply neglects to register it and instead uses the existing one. Thusly, if someone writes a miniServ Plugin that does a more full-featured HTTP server, then your UFS plugin would check, see the API is already registered, and go 'okiedokie, I'll just use that' instead of registering it. Otherwise... if you had, say, nowPlaying (or 'http-server' or whatever) implemented by more than one plugin, how would the plugin calling into it know which to use? If I'm using 'nowPlaying' and the user has winamp.dll, TrillyTunes, and something else loaded, how will my plugin know which one to call to get currently playing data, etc? Do I make the user pick one? Would be ugly, etc.
• If you wanted to still do what you want, I would suggest (for instance) writing a plugin which took over the nowPlaying API, scanned (by GUID) for all the media players it knew about, and then just forwarded (using GUIDs) the calls to whichever you had set as 'current.' Then you have a preferences page for that plugin which has a drop-down list of all the detected media players installed, and lets you pick which one to pull 'currently playing' song data from, send 'play song' commands to, etc. Does that help?

--Sparks 20:05, 12 Dec 2005 (CST)

[edit] Random Comments

• Thanks for helping clean up the spam. I've just upgraded the wiki and installed some new spam-blocking extensions, so hopefully we'll stop seeing it. --Sparks 03:21, 6 January 2006 (CST)

• You're welcome :-) I noticed that since the software upgrade there is another not needed menu entry. So how about removing "Current events", "Donations" and perhaps also "Community portal"? --KingIR 14:16, 8 January 2006 (CET)

• I've finally caved; the wiki can only be edited when logged in. Users will have to create an account to edit the wiki at all. :P --Sparks 13:06, 19 February 2006 (CST)

• *sniff* I'll miss the daily spam! ;-) --KingIR 22:57, 19 February 2006 (CET)

• I can go add some spam, just for you? :P --Sparks 18:36, 21 February 2006 (CST)

[edit] TrillyTunes

• As a side note, I notice that one TrillyTunes function (TrillyTunesGoPlay) doesn't give an API code, and the other (TrillyTunesPlaylistEnum) gives the function as the API name. Is this really right? Usually, the API name is something else... like how the 'upnpWhatever' functions are provided by the 'upnp' API, and how all of the ufs functions in eh?one's UFS plugin are provided by a 'ufs' API. Figured I'd better check... :) --Sparks 11:39, 26 March 2006 (CST)

• Well, I see what you mean, and I also see that it's definitely not the tidiest way the API is designed. Anyhow, I think that pluginExternalEnumerateAPI actually does return the GUID for each function which has been registered with pluginRegisterAPI, so there's no real need for a function which is only there for GUID discovering. (speaking of stylistic means, it's nice nevertheless :P) Should I be wrong there? :O If I am, the heck with it, there's no other plugin providing the API and I also don't plan on changing the GUID (insert second part of first sentence here :P). If I recall correctly, eh?one also used it this way in one of his upcoming plugins. --KingIR 21:51, 26 March 2006 (CET)

• No, pluginExternalEnumerateAPI is intended to enumerate whatever plugins provide a specific API by name. For instance, all the UPnP functions are grouped into a single "upnp" API... look at how upnpRegisterPort is written up. It looks up the "upnp" API, and (upon getting that GUID back) goes 'ah-ha, there it is.' and can then use that GUID for inter-plugin communication. Or eh?one's ufsAddShare, notice it looks up "ufs" because that's the name of the overall API. Let's say I have a 'sparks' API and you have a 'kingir' API; both of us can have a 'fooBarBlah' function without collision, because the APIs are named differently; it's not immediately apparent because most people have followed our internal Cerulean naming convention, i.e. naming everything along the lines of categoryAction or categoryActionObject (upnpRegisterPort, contactlistEnum, etc.) Does that help explain better? --Sparks 03:30, 27 March 2006 (CST)

• D'oh! Shame on me. Going to do that in a proper way in Trilly Tunes 2.0, sorry for the mess. Anyway, thanks you took the time to point it out once again, I really appreciate that :) --KingIR 22:35, 28 March 2006 (CET)

[edit] Skinning information

Can you create pages on skinning your plugins and add them to Category:Plugin Skinning please? Thanks. -- Tometheus (talk) 14:39, 16 April 2007 (EDT)