On Mon, Sep 20, 2010 at 11:37 PM, Nathan Anderson <[email protected]<mailto:[email protected]>> wrote: > > Here are some Real world numbers using real applications; pulled from > Maemo > > Repositories > > ICU 4.2> 8 Megs > > cLucene is> 3 Meg (Depends on ICU) > > Sword> 2 Megs. (Depends on cLucene) > > WebKit> 3 Megs. (Depends on ICU 4.2) > > > Lets say I just put TWO bible apps (Both use Sword) on the device; > > Lets say Rapier: which is 35K And Katana: which is 94k > > >>Which is pretty much the pathological corner case, not the average real > world scenario. > > > You might be correct -- they might be a corner case; but it IS from > REAL data that _I_ could easily supply since _I_ packaged them and _I_ was > very familure with the projects that use them. Quim made a comment, I > responded with REAL information that came from stuff _I_ did on Maemo. > http://maemo.org/packages/package_instance/view/fremantle_extras-testing > _fre > e_armel/clucene-core/0.9.21b-0maemo1/ > > > >>We need to engineer around average use cases, rather than focusing on > >>corner cases. Highlighting extremities makes great theater like this > >>thread shows, but doesn't bring us towards solutions. > > However, it is a VALID USE case, what about Python, Ruby, or PHP, Java or > any number of any number of other scripting languages, or even things like > Boost or even liqbase. LOL, I can think of a dozen items off the top of > my head that are large, so it isn't a isolated case. My point was we need > to be careful about "requiring" inclusive packages. It wasn't about > ICU/Webkit, I just was trying to bring in some real numbers that I had some > idea about since _I_ packaged them up for Maemo. >
I do agree we need more data support for the final decision of the two opinions: Only MeeGo Core dependencies or Extra repo is acceptable. We may need to ask ourselves these questions. How many applications only have MeeGo Core dependencies and how many applications do need Extra repo support? What kinds of packages should be better to be provided through Extra repo and what kinds of packages are better to be static linked? What's the trend of applications development w/ and w/o Extra repo? Is it possible for us to get a clean MeeGo Eco-system with all or a considerable percents (say >95%) of applications with only MeeGo Core dependencies? And when will it happen? What will be preferred way for experienced developers and what for newbie? IMO, it might be not practicable to apply a strict compliance spec(Only MeeGo Core dependency are allowed). First we are different with Android or iOS, which can apply a strict compliance rule in a different Eco-system. Android provides the strict CTS since the Android application development is totally new for developers and there had been ZERO Android app before 2008. Android did not need to consider much about like Extra libs. Apple iPhone/iPad application compliance and the app-store is central controlled. All applications for Android and iPhone/iPad come from their SDK without other choice. But MeeGo is different. MeeGo will reuse many existing applications. They have been there before MeeGo SDK. Can we apply a strict compliance spec to force them to change or exclude them from MeeGo? If the number of those applications is relatively big(say >30%) and they are really good applications, we should embrace them without a big barrier like statically linking all non-Core depe ndencies. (Even Android has the strict CTS, it has to provide NDK for development.) So at beginning, we may need a more flexible but still practicable compliance definition for MeeGo. I think to use 2 levels of compliance is practicable as following. On Thu, Sep 16, 2010 at 4:42 PM, Warren Baird <[email protected]<mailto:[email protected]>> wrote: > > Earlier in the thread there was discussion around 2 levels of > compliance - a 'strict' compliance that requires inclusion of all > dependencies, and a more relaxed compliance that allows dependencies > on an 'Extras' style repository... I agree with that and I think we also need to enforce the "Extra" compliance. See following proposal: 1. There can be 2 levels of compliance: MeeGo Core Compliance (strict) and MeeGo Optional Compliance (relaxed). Both should be specified in MeeGo Compliance Spec. a) MeeGo Core Compliant applications have only MeeGo Core dependencies. MeeGo Core dependencies are enough to develop a full featured MeeGo application. It's bound with MeeGo Architecture and APIs. b) MeeGo Optional Compliant applications have both MeeGo Core and MeeGo Optional dependencies. c) MeeGo Optional dependencies provides complement to MeeGo Core dependencies. The packages defined in MeeGo Optional dependencies should be also fine-specified in same way as the packages in MeeGo Core so it guarantees the compatibility between implementations. The MeeGo Optional may be presented as an Extra repo. d) Both MeeGo Core and Optional are defined in MeeGo Compliance spec. MeeGo Core shall be and MeeGo Optional is optional applied in MeeGo devices. The packages will be selected into Core based on the MeeGo Architecture and API definition and be selected into Optional based on popularity of it. Only adding packages are permitted for backward-compatibility. Removing of package only happens with approved data support (something like there is <%0.5 apps share that package.). e) For any other packages not in Core or Optional, they are not defined in MeeGo Compliance and up to different implementations. Applications on top of those packages are not MeeGo compliant. 2. All implementation of MeeGo Optional repo should follow MeeGo Optional compliance so there will be no conflicts between different MeeGo Optional repos. But vendors have choice to include a MeeGo Optional repo or not. They also have choice to use part of MeeGo Optional or use full set of it. My assumption is package conflict is a more complicate problem than just package missing. 3. Any MeeGo Core Compliant application will be able to run on all MeeGo Core compliant devices. And they can be installed through app-installer provided by vendors or they can be installed stand-alone from web downloading. 4. The MeeGo Optional Compliant application can only be installed through an specific app-installer, which should be deployed by device vendor or application provider and the corresponding MeeGo Optional repos will be provided as well. The stand-alone installation is not guaranteed. So the MeeGo Optional Compliant application may not be able to run on all MeeGo devices but it's guaranteed to run on MeeGo devices with the specific app-installer. If the developer want it be included in multiple devices with different MeeGo Optional repos, they need to submit it multiple times. And developer will be aware of the non-guaranteed installation issue and will not put the rpm somewhere for stand-alone downloading. The benefit and constrains might be: 1. MeeGo Core Compliance is till be promoted for any new MeeGo applications development and it provides maximum benefit for all stakeholders. 2. MeeGo Optional Compliance will be mostly used for existing work but not recommended for new applications. The developers and vendors will got benefit on TTM. 3. The developers using non-Core dependencies get major benefit from the Optional compliance and only have small burden on application distribution and maintenance, mostly will be a new submission to a new MeeGo Optional Compliant Repo or Store. On the other side, they have to link some statically libs when they encounter any problem. Not worse than the strict compliance. 4. The MeeGo Optional is always a complement to MeeGo Core before MeeGo Core goes to mature and popular enough. It's a tradeoff between the only MeeGo Core goal and the reality of existing situation. We cannot predict how those optional libs like SDL or ICU be used in future MeeGo applications. Something will opt-in and something will opt-out along with evolvement of MeeGo. But at this stage, looks like they are important for many existing work (as mentioned by some developer before) and they are not good to be linked statically and they actually should be specifically defined for some MeeGo developers. 5. End user will have no trouble to install any kinds of applications with app-installer. They probably have trouble to install MeeGo Optional Compliant application in stand-alone way. But application provider is supposed to not distribute apps in that way since they know the problem (I hope so but not sure :)). 6. The MeeGo Core and MeeGo Optional cannot meet all needs of developers but hopefully can meet most, especially for existing apps. 7. MeeGo Community has burden to maintain the compliance of those MeeGo Optional packages. 8. Device vendor has more flexibility to customize their MeeGo Optional Repo considering their hardware profiles. If multiple MeeGo Optional Repos are provided, they will not conflict! In practice, looking into MeeGo OBS, the Trunk project actually can be split into MeeGo Core and MeeGo Optional packages. We can look into that initial set of packages to select which is for Core and which can be optional. For instance, the Python, SDL, ICU have been there and can be selected in MeeGo Optional to solve a large part of non-Core compliant applications (if some assumptions are true). Cheers! - Jackie PS: Just getting involved and personal opinions only. I don't have data support as well. :) > > _______________________________________________ > MeeGo-dev mailing list > [email protected]<mailto:[email protected]> > http://lists.meego.com/listinfo/meego-dev _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
