View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003360 | MMW v4 | Other | public | 2007-08-02 22:49 | 2016-12-01 17:32 |
| Reporter | jiri | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Fixed in Version | 4.0 | ||||
| Summary | 0003360: Use single internet access library instead of TIE + Indy | ||||
| Description | Currently we use TIE component for only some connections, we should use it for all and thus don't need Indy at all. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1304 | ||||
| related to | 0003119 | closed | Ludek | MMW v4 | Podcasting: many feeds appear empty |
| related to | 0004976 | closed | Ludek | MMW v4 | Extensions: Support for Additional browser header info |
| related to | 0005373 | closed | Ludek | MMW v4 | IE8 triggers connection problems (wininet error) on Vista / Windows 2008 |
| related to | 0005001 | closed | Ludek | MMW v4 | Regression: Some podcast feeds no longer work |
| related to | 0006320 | closed | Ludek | MMW v4 | Framework: Retrieve URL data |
| related to | 0004353 | closed | Ludek | MMW v4 | Add hidden config entry to prefer TIE when auto-tag from web |
| related to | 0004970 | closed | peke | MMW v4 | Component Updated: New TIEHTTP Release |
| related to | 0005230 | closed | Ludek | MMW v4 | Proxy setting configuration doesn't work as expected |
| related to | 0005410 | closed | peke | Last.fm plugin | Last.fm misc engine improvements |
| related to | 0001293 | closed | Ludek | MMW v4 | Download Manager |
| related to | 0005437 | closed | peke | Last.fm plugin | Last.fm Scrobbler connection problems when IE8 Installed |
| related to | 0006215 | resolved | jiri | MMW v4 | Support for auto-proxy configuration via PAC script files |
| related to | 0011905 | resolved | Ludek | MMW v4 | [Specification Confirmation] About Download Timeout |
| related to | 0013071 | closed | Ludek | MMW v4 | Penny Arcade Podcast fails with SSL error |
| Not all the children of this issue are yet resolved or closed. | |||||
|
|
The Indy is now used only in CDDBUtils.pas (for CDDB requests). I would rather wait (with rewriting that code) until we ensure that TIE does not bring any problems to prevent boondoggle (redundant work). So the priority would be decreased a little. e.g. I had to modified TIE to be thread safe, it wasn't and could generate an AV as can be seen in some EL files. |
|
|
Also TIE seems to have a problem with HTTP reading for some users on some systems, see http://www.mediamonkey.com/forum/viewtopic.php?t=22189 I'm going to temporary use Indy again (only for Amazon reading - as is in MM 2.5) in order to ensure that the problem is caused by using TIE. Note: I guess we will need to find another HTTP library for MM 3.1 (Both TIE or Indy seem to be buggy) |
|
|
Because of http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=3584¬econfirm=1 and problems related to TIE update (bug 0004970) we should try to find another HTTP library, currently both TIE and Indy (bug 0003119) seem to be buggy and don't satisfy all our needs. |
|
|
I have tested New Tie And no issues with any of example feeds in 0005001 Except few glitches when non Deflate page is loaded it looks that TIE Mixes gzip/gunzip decoding even page is pure HTML/Text. |
|
|
Deferred to MM 3.2 |
|
|
Using risk free method I've added few additional headers to TIE Component that should tell servers to better format requested URL. More details about issue in 0004976 |
|
|
Ludek, I was investigating one more thing regarding current implementation and have found that various applications are capable to change internet explorers context menu. Additionally there is always approach where sites made to be seen in MM can return any type of document (like find updates return XML)so that we can internally create object with already existing functions using Active MediaMonkey Skin (Apple store forces usage of iTunes for browsing). But as you already pointed and talked with Jiri long term solution would be to make our own internal browser or even better combination of both. Have you asked Sven Harazim to send us his HTTP functions for test? After stable 3.1 we can make meeting to gather all ideas and see how to proceed next. |
|
|
Yes, Sven posted v3.53 is Freeware (Attachment on our FTP) 3.6x http://sourceforge.net/projects/alcinoe/ is GPL I have tried the demo and it looks fine ;-) Many more functions than TIEHTTP and much better written. In addition all the problematic feeds seem to work. |
|
|
I Assign to Myself due the fact that I have fully operational web server on my lan for purpose of testing MediaMonkey Web Functions/Functionality. |
|
|
Reminder sent to: rusty Rusty, I agree with Ludek that Alcinoe Common HTTP Functions are much better and cleaner than TIE. Here is license text from v3.69 Version and I do not see issues with using it. ----- All files included in the archive are Copyright (C) 1999-2009 by Arkadia Software Engineering The component is fully free. You can use it any kind of software. But you must point to original author in your program about window or in help file. Alcinoe component License Agreement. Use and distribution of the component is permitted provided that all of the following terms are accepted: The component is provided "as-is," without any express or implied warranty. In no event shall the Author be held liable for any damages arising from the use of the Software. You can modify and redistribute source code as you wish. If you do not agree to all of the above terms, you are not permitted to use the Software in any way, and all copies of it must be deleted from your system(s). ----- |
|
|
Just a note that we are trying to integrate WebKit (free and open source core of Safari browser) advantaged with platform independence. So we will see later whether Alcione or WebKit would be a solution. In case we will integrate WebKit then we should try to use it for all internet access. |
|
|
http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=5045 Just to note to other dev. team I've been with this user in few crossloop sessions for few hours and even got users account access to last.fm. No issues on my PC and on other user PC only on one that I was examining, and it looks that TIE is responsible in the way that it can't access wininet libraries. Luckily for now these are isolated issues with last.fm I'll try to do more tests in next few days on Alcoine as it is Delphi source. |
|
|
v3.53 is Freeware is uploaded to FTP under this bug number |
|
|
I've discussed with Peke the pros and cons of WebKit: The conclusion is that it looks like MM could live without WebKit or any integrated Web Browser, solution is: MM should offer a common API for the servers like HDTRacks, AllMusic, Amazon etc. This API will accept kind of XML formatted for MM. Advantages: 1. All the sites will really looks like integrated to MM UI 2. This will be much more secure, just XML will be posted to the MM 3. We won't need to include probably MBs of WebKit and thus the instalation package won't grow up. 4. We won't be dependent on this third party component (WebKit) and bugs related to the component EDIT Peke: 5. it is platform independent (as it will use standard IP Packets and Textual/binary data) 6. Can be build up on existing scripting API 7. Can be easily ported to be used on any web platform Server (PHP, ASP,...) or existing Modular Solutions like Facebook, MySpace, Joomla, Mambo, ... 8. Can take Affiliate/Partnership benefits like Apple store is integrated browsing thrum iTunes or MediaGuide in WMP. 9. In future versions it can be Two Way so that MediaMonkey create response messages pages (DLNA, LCD TV Browsers, MediaCenter applications, Web Apps like WAWI, Widgets). Something like Opera browser integrated server into browser |
|
|
Some Cons: 1. We will need to make API easy understandable and examples Available in multiple Languages like PHP, ASP,... but keep it similar to existing Scripting API EDIT by Ludek: 2. We will need to force all the sites we currently have in MM interface (AllMusic.com, HDTracks.com, eMusic, CDUniverse.com, Amazon.com, IceCast, SouthCast) to use our API and it could take a longer time. |
|
|
Ludek, Can you clarify what you mean when you say that "MM should offer a common API for the servers like HDTRacks, AllMusic, Amazon etc. This API will accept kind of XML formatted for MM." It's not realistic to expect these third parties to change the format of their data to match our requirements, but I'm not sure if that's what you're saying. Edit by Ludek: There is also possibility to have our own server that would filter and reformat the HTML sites for us and would send us only the formatted XML. This way we don't need to force the third parties like AllMusic.com, HDTracks.com to use our API, but our server would format the HTML content to our API automatically. Edit By Peke (Addon for above): If combined with scripting almost any site could be shown in MM native look, as scripters could easily use MM API to create translation of virtually any site and help us to add more API objects much easily. |
|
|
I have made a research of WebKit project today and here are some important links: 1. It’s not a browser. WebKit is a browser engine: http://webkit.org/blog/101/back-to-basics/ 2. The only working version of WebKit that does not use any proprietary Apple libraries seems to be this one: http://lwat.blogspot.com/2008/11/redistributable-webkit.html This WebKit differs from the true Safari webkit as follows: No support for QuickTime movies. CFNetwork is replaced by cURL, which implies some reduced functionality and poorer support for concurrent/asynchronous connections. CoreFoundation is replaced by CFLite, which for the purposes of WebKit should not imply any performance or functionality regression. CoreGraphics is replaced by Cairo. This generally trails the CoreGraphics implementation, but provides reasonable performance and functionality. Build steps for the Cairo (all redistributable) are here: http://trac.webkit.org/wiki/BuildingCairoOnWindows Size of WebKit.dll is 6 MBs, but there are some others DLLs needed like icudt40.dll which takes 14 MBs, but it is one of ICU (http://www-01.ibm.com/software/globalization/icu/index.jsp ) libs and we could try to somehow disintegrate it. |
|
|
Based on discussion with Jiri we decided to defer WebKit integration until we are platform independent for several reasons. So for now would be the best to integrate another internet access library that would replace TIE and Indy. The ALCINOE looks fine, I have made a little research and it is well written, all the problematic feeds (that didn't work with TIE xor Indy) seem to work. The main difference is that Alcinoe can use both Windows HTTP Services (WinHTTP) and WinInet, but TIE uses only WinInet. WinHTTP is more secure and robust than WinInet. However, single-user applications that need FTP or gopher functionality, cookie persistence, caching, automatic credential dialog handling, Internet Explorer compatibility, or downlevel platform support should still consider using WinInet. See http://msdn.microsoft.com/en-us/library/ms950426.aspx and http://msdn.microsoft.com/en-us/library/aa382925(VS.85).aspx for more info. Mainly this one: http://msdn.microsoft.com/en-us/library/aa384068(VS.85).aspx seems to be useful. Another advantage of porting from WinInet to WinHTTP is auto-proxy support, see: http://msdn.microsoft.com/en-us/library/aa383910(VS.85).aspx http://msdn.microsoft.com/en-us/library/aa384240(VS.85).aspx |
|
|
Removed dependencies on TIE and Indy internet access libraries, we use Alcinoe for all http access now (podcasting, file downloading, auto-tag from web, file streaming, CDDB queries, OPML directory browsing, etc.) Tested and I haven't found a regression/problem so far. Added in build 1300. |
|
|
Important note: I reverted to Indy 10 (Internet Direct) using Windows Sockets 2 for several reasons: 1. I found out that the issues because of we deprecated Indy (e.g. issue 0003119) no longer occurs. 2. It uses windows sockets (lower level then WinInet or WinHTTP) which allows us to use Indy for all internet protocols and schemes (not only HTTP and HTTPS) Pros of Alcinoe: + MediaMonkey.exe is smaller (- 85 KB), because it uses high level WinInet.dll Cons of Alcinoe: - it uses WinInet or WinHTTP which is a higher level and restrict Alcinoe to use only HTTP and HTTPS schemes - it is not unicode ready and ready for Delphi 2010 so I had to modify the code, now it works right - it is a standalone third party library (not a part of RAD Studio 2010) Pros of Indy 10: + It is unicode ready and integrated to Delphi 2010 + It uses WinSock2.dll (windows sockets 2) and therefore it supports also the others schemes than http and https + Time to compile MediaMonkey.exe is shorter Cons of Indy 10: - MediaMonkey.exe is larger (+ 85 KB) Conclusion: I am going to start MediaMonkey 4.0 test cycle with Indy 10 and in case of any significant problems we can whenever revert to Alcinoe (just under ALCINOE compiler directive) Indy included in build 1304. |
|
|
Ludek, Is it possible to create solution for 0004976 under Indy. Like TIE and Alcoine is capable? |
|
|
Closing and no issues with Win 7, IE9, IE8 and all versions from 1304-1335 Re-verified 1335 |
