(2013-05-30, 18:32)bodrick Wrote: I totally agree with you on the source code, it is a bit of a mismatch hodpodge of code tacked on and bandaided. I actually spent a lot of time reworking some of it in my 2.0 branch that could be applied potentially to the 1.4 branch, some being the simplification of the settings etc. I also have potentially code that could eliminate our need to keep maintaining updated scrapers, and instead use the scrapers that come with XBMC, the functionality had been part of Ember a long time ago, but it was broken for the longest time, I updated it and worked with Olympia in testing and making sure it worked. That was for Eden, I'm not sure about Frodo but I suspect the changes won't be too bad to implement.
That is the XML Scraper, if you are able to have it work great. But I would NOT replace the scrapers, will provide more info below.
For the code you have prepared for 2.0 let us know, happy to see it.
Please note that we have been working heavily on the internal structure of the picture management (now is all in memory, downloading only thumbs, optimizing network traffic, optimizing quality) and I've tried to make it easy to extend to other pictures (cd art, clear art, etc).
(2013-05-30, 18:32)bodrick Wrote: In regards to the EntityFramework, I've been developing with it now for a couple of years for my job and have to admit its been a good choice for my projects. You can really achieve some amazing stuff with it that would be very hard to comprehend in just straight SQL, and trust me I tried lol. So obviously its up to the rest of the team to offer their opinions etc.
Open to their opinions too
(2013-05-30, 18:32)bodrick Wrote: Another thing that I was working on and I don't know if you would agree or disagree, but I believe the Module/Plugin framework is a waste of time, hard to maintain and overcomplicates everything. I understand the reasoning for doing it, but in the whole time I don't think anyone wrote a single module for Ember that wasn't part of the original team, with maybe minor exceptions for band aiding scraper functionality. The downside is the Module/Plugin framework is very tightly woven into Ember, I've spent a lot of time trying to purge it but haven't got there yet. I'm wondering if maybe there is a way to incorporate the work I've done with the work you guys have done. Something we should discuss going forward.
bodrick, I do agree on some points but my approach (and the one in 1.4 we are following) is to split ALL the scrapers into independent modules.
the idea of external module is very good because gives a lot of flexibility and agility to add new metadata or picture sources.
Having a monolithic program is bad and will lead to an unmanageable codebase.
If you look at the new scrapers I've done they are all lightweight, very simple and very efficient; this is how they should have been since day 0.
the "macro scraper" IMDB and TV together was a mess.
Also I'm planning to SPLIT the multifunction modules into separate. EVERY function should be an independent module! with it's own project.
In this way the code will be clean, easy to maintain and bugs will not propagate widely.
I've started to clean up a lot of the code so I'd suggest you review the 1.4 codebase
(2013-05-30, 18:35)DanCooper Wrote: (2013-05-30, 15:08)m.savazzi Wrote: DanCooper,
have you added this?
LOL
you need to fix it
Yes that was me 
I had not sorted clean since many changes are necessary (in the settings). I would like to reduce the setting where we have a check box for XBMC and one for YAMJ. In addition, a separate window with "expert" settings.
Dan,
not clear what you want to do there
can you explain better?
The YAMJ module, if I remember correctly, is part of the mess module multi.somthing. I will chop them into all different modules as now they are a code mess :S
Do you agree?
If you are able to simply the settings it's great but in the end works quite fine
(is bad to change but from a user perspective it works)
M
(2013-05-31, 19:47)Cocotus Wrote: First: Wooot bodrick, welcome!
Second: My knowledge of entity framework is.....NONE. but my knowledge of SQL isn't that great either, so IMO I can live with both solutions. I don't know whats better and worse. But I suspect the effort to switch from SQL in Ember to something new for database queries, is quite overwhelming so my vote goes to: SQL queries old style! BTW, I will start to work on the feature points as soon we have a 1.4 version set up with new database. Do we still need to port all the changes from latest 1.3 version to 1.4, or is that step already done by Dan?
I think Dan have to do some cleanup.
Cocotus I would suggest you start to create an independent scraper for Trak.tv
(it should be easy starting from the new Data scrapers)
Also you may check if there is any functionality is not mainly impacted from the DB changes.
Let's see what Dan prefers but maybe we can keep SQL in this phase and then, if we see too many limitations, swap to EF later...
The change of the DB structure will reflect on the internal data structure and thus I expect on a lot of the modules... (AND we have to make sure all DB access is done via the DB Class and not directly in other parts of the code)
... while once that the DB is in place swapping SQL to EF should be essentially limited to the DB class. Easier to manage
Probably a two step (update DB and SQL and then swap to EF if better) is the safest approach...
M
