Quantcast Thoughts on external libraries. - LoTROInterface
lotrointerface.com
Search Downloads


Go Back   LoTROInterface > LotRO > Developer Discussions > General Authoring Discussion (L)

Reply
Thread Tools Display Modes
  #1  
Unread 11-04-2010, 05:13 PM
Digital_Utopia's Avatar
Digital_Utopia Digital_Utopia is offline
The Undying
Interface Author - Click to view interfaces
 
Join Date: Sep 2010
Posts: 207
Send a message via MSN to Digital_Utopia Send a message via Yahoo to Digital_Utopia
Thoughts on external libraries.

I've been thinking a bit on the current folder structure when it comes to external libraries, in comparison to the way WoW's add-ons are done. Currently with LotRO, the general rule of thumb has been to treat external libraries like plugins themselves - in other words, install them in your plugin folder, in the Author's name folder. For instance, in my case - DUInterface would be stored in the DigitalUtopia folder, and any plugin that wishes to use that library, has to access it through that path.

On the other hand, WoW treats each add-on as its own entity, generally keeping everything that add-on needs to function, within that add-on's folder - including external libraries. I feel that this presents four advantages to the current LotRO setup:

1) No matter what changes the library's author makes - that version of the add-on will always use the version it was written for
2) It avoids a certain add-on version of "dll hell" where adding a future add-on that uses a different version of a shared library could cause an older add-on to break.
3) Unlike plugins and their .plugin file, libraries have no method to declare a version number, requiring authors to manually place some form of info file for any future update services (i.e. curse client, minion, LMM, etc)
4) Add-on authors aren't at the mercy of the library author. While using any other code than your own does require you to depend on a library author, it's a far better situation than if you had to immediately release an update should a library author change something.

For those reasons, I think it would be better to adopt that method of external library usage. However, that is merely my opinion, so I'd really like to hear from other authors here as to their own.
__________________

Lord of the Rings Online
75 Fourohfour | 75 Artemedis | 60 Whiskeytango Foxtrot | 50 Mistah Boombastic | 56 Appetizer | 25 Aggromi
61 Onepointtwentyone Gigawatts


World of Warcraft
90 Downlo 85 Gravetaxi 85 Ümad 85 Artemedis 85 Guthuros
Reply With Quote
  #2  
Unread 11-04-2010, 06:07 PM
D.H1cks's Avatar
D.H1cks D.H1cks is offline
The Undying
Interface Author - Click to view interfaces
 
Join Date: Apr 2007
Posts: 162
I think we have the same view.

I do not like using external libraries at all for my plugins. I have made use of other's work, with credit given where due, but incorporate that work into my plugin's folder structure. (check the folder structure of the Travel Window plugin to see what I mean.)

At the same time, I have my own libraries that I use which are external to the plugins. I don't have any issue with that, because it is my own and I know that any changes I make to them will need to be checked on all my plugins. It is not my intention to ever release my libraries as stand alone downloads.
Reply With Quote
  #3  
Unread 11-06-2010, 12:56 AM
Oliner Oliner is offline
The Undefeated
 
Join Date: Mar 2009
Posts: 7
WOW has the problem that a library loaded with one addon is the one that is globally referenced, and if another addon needs another version, this causes issues. It also causes more disk space to be consumed. The old WOWAce updater even allowed you to "unwind" library dependencies so they were stored at the top level and only one time.

One way that many of the addons have used to stay in sync on libraries is the use of a centralized development site like WOWAce/CurseForge which provides the libraries to the plugin authors plus provides the tools to allow the plugin author to automatically generate a ZIP file containing all the correct libraries along with the current release of code.

You might get better return on time invested by building up tools around the LOTROInterface SVN repository that allows authors to pull current versions of another author's code automatically as they build releases. This alone would eliminate many of the version problems, so long as the author is active. And for inactive plugins, there's really not much to be done unless someone else adopts it and runs with it.
Reply With Quote
  #4  
Unread 11-06-2010, 01:59 AM
Digital_Utopia's Avatar
Digital_Utopia Digital_Utopia is offline
The Undying
Interface Author - Click to view interfaces
 
Join Date: Sep 2010
Posts: 207
Send a message via MSN to Digital_Utopia Send a message via Yahoo to Digital_Utopia
Quote:
Originally Posted by Oliner
WOW has the problem that a library loaded with one addon is the one that is globally referenced, and if another addon needs another version, this causes issues. It also causes more disk space to be consumed. The old WOWAce updater even allowed you to "unwind" library dependencies so they were stored at the top level and only one time.

One way that many of the addons have used to stay in sync on libraries is the use of a centralized development site like WOWAce/CurseForge which provides the libraries to the plugin authors plus provides the tools to allow the plugin author to automatically generate a ZIP file containing all the correct libraries along with the current release of code.

You might get better return on time invested by building up tools around the LOTROInterface SVN repository that allows authors to pull current versions of another author's code automatically as they build releases. This alone would eliminate many of the version problems, so long as the author is active. And for inactive plugins, there's really not much to be done unless someone else adopts it and runs with it.
Since Libraries in LotRO are nothing more than scripts - thus allowing each plugin to use the same class in different paths. So for instance if Plugin1 imports Plugin1/Class1, and Plugin2 imports Plugin2/Class1, both work independently of the other. As far as disk space goes, I'm having trouble seeing a situation where any library is going to use enough space for this to even matter. Even DUInterface, with its 5 different UI elements, and related images doesn't even break 400 KB.

Regarding syncing, that's not the big issue. The issue is once a plugin is stable and mature that author could still be forced to update that plugin - for no other reason than to prevent it from breaking due to a library update. Not because of an API change, not because the library itself allowed the author to improve the plugin, but just so that the plugin continues to function. That just seems to me as a little unfair to be at the mercy of another author - after the plugin is already mature.
__________________

Lord of the Rings Online
75 Fourohfour | 75 Artemedis | 60 Whiskeytango Foxtrot | 50 Mistah Boombastic | 56 Appetizer | 25 Aggromi
61 Onepointtwentyone Gigawatts


World of Warcraft
90 Downlo 85 Gravetaxi 85 Ümad 85 Artemedis 85 Guthuros
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
A New External Lotro Mod Manager Bredic Script & Skin Managers 14 11-23-2010 07:25 AM


All times are GMT -5. The time now is 03:47 AM.


Our Network
EQInterface | EQ2Interface | Minion | WoWInterface | ESOUI | LoTROInterface | MMOUI | Swtorui