Page 7 of 11 FirstFirst ... 234567891011 LastLast
Results 121 to 140 of 201
  1. #121  
    Quote Originally Posted by Macwinux View Post
    Palm has turned into a bunch of script kiddies. They can't compete with Apple on their own merits. They have to use Apple's own work to pretend they are contenders. They are still just take over bait.

    Enjoy.
    Awww comon Palm is only doing what Apple users god and savior Steve Jobs does.

    IE:
  2. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #122  
    Quote Originally Posted by sivan View Post
    I wanted to clarify that it's not an API because an API implies that Apple is actively helping anyone who wants to work with iTunes and that Palm is asking for more.
    I use webOS APIs and nobody is actively helping me. I use the iPhone SDK and nobody is actively helping me. If I want help, I can cash in a tech support incident with Apple and get help on anything in their realm, including that iTunes XML interface. That's how they support registered developers.

    It doesn't have to be purposefully. That file is there for legacy reasons, it's arcane and bizarrely constructed. It really is a serialized property list, a Mac OS X convention. It's not made for consumption by third parties.
    Nah, it's a standard XML file. I just parsed it with xmllint on the command line and it worked fine. I work with XML files for my day job, and this one is meticulously crafted and completely standard.

    Code:
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
      <dict>
        <key>Major Version</key>
        <integer>1</integer>
        <key>Minor Version</key>
        <integer>1</integer>
        <key>Application Version</key>
        <string>9.0</string>
        <key>Features</key>
        <integer>5</integer>
        <key>Show Content Ratings</key>
        <true/>
        <key>Music Folder</key>
        <string>file://localhost/Users/hsh/Music/iTunes/iTunes%20Music/</string>
        <key>Library Persistent ID</key>
        <string>4569FE9387D6212A</string>
        <key>Tracks</key>
        <dict>
          <key>583</key>
          <dict>
            <key>Track ID</key>
            <integer>583</integer>
            <key>Name</key>
            <string>Forget About It</string>
            <key>Artist</key>
            <string>Alison Krauss</string>
            <key>Album</key>
            <string>Forget About It</string>
            <key>Genre</key>
            <string>Country</string>
            <key>Kind</key>
            <string>MPEG audio file</string>
    
     etc...
    Ah, I knew someone would jump at that. Companies that maintain an API have an obligation to keep it stable and documented as long as feasible. That's why Sun's Java is still backward compatible and Microsoft still supports Win32: because they handed out SDKs and promised to support them for the foreseeable future. And when change comes it is announced well in advance and is done with care to not break clients that depend on it.
    In the world of software development, one word we're used to dealing with a lot is "deprecated". We constantly have to come up with fixes and workarounds for stuff that is no longer supported. Or stuff that gets superseded. I'd estimate that makes up at least 20% of my job on average, sometimes more.

    But Apple made no such promise to anyone when it comes to iTunes. At most you can say that Apple tolerates 3rd party access to it but it has no arrangement with them and can change that file at will, make it a binary or stash it in a mini database. All the companies promising their customers iTunes sync do it independently of Apple and just like Palm are promising something Apple did not endorse in any way. There is nothing especially shady about what Palm is doing, the vendor ID is an implementation detail.
    I think you want to believe all that, but I disagree. I am pretty familiar with the Mac OSX, iPhone, and webOS (Mojo) SDKs right now, and none of them have made any promises to me. In fact, part of the agreement for the webOS SDK reads as follows:

    11.1 Development Support. Palm shall have no obligation pursuant to this Agreement to provide Developer with any support regarding the Palm Materials. Notwithstanding any other provisions of this Agreement, Palm shall have no obligation to provide Developer with any updates to the Palm Materials. Palm shall have no obligation to provide any maintenance or support for the Applications under this Agreement.
    and

    12.2 Palm Materials. DEVELOPER EXPRESSLY ACKNOWLEDGES AND AGREES THAT:

    (a) USE OF THE PALM MATERIALS IS AT DEVELOPERíS SOLE RISK AND THE PALM MATERIALS ARE PROVIDED "AS IS" AND WITHOUT WARRANTY OF ANY KIND AND PALM AND ITS SUPPLIERS EXPRESSLY DISCLAIM ALL WARRANTIES, TERMS AND CONDITIONS, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES, TERMS AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT OF THIRD PARTY RIGHTS AND SATISFACTORY QUALITY;

    Almost every SDK agreement I have seen has some sort of section like that. Basically, you're entering into the agreement in good faith. I've never been burned in a big way, but I also have never been under any impression that there was a safety net. Software technology advances at a pretty good pace, and changes happen all the time.
  3. #123  
    And that makes Palm what?
  4. #124  
    Quote Originally Posted by Adjei View Post
    This is the dumbest analogy I have ever heard. Last time I checked iTunes is a free program, Apple doesn't sell it. Secondly the majority of iPod and iPhone users use Windows therefore it's only appropriate for iTunes to be released for it. Thirdly iTunes is required to put songs on an iPod or iPhone. You don't need iTunes to put stuff on your Pre. In your rant you never mentioned why Palm is now advertising syncing photos with iTunes or is Apppe also selling photos that need to be synced.
    My rant?? Oh, I see, disagreeing with you is both "dumb" and a rant. My bad...
  5. #125  
    Quote Originally Posted by Adjei View Post
    ...
    In your rant you never mentioned why Palm is now advertising syncing photos with iTunes or is Apppe also selling photos that need to be synced.
    I think I previously mentioned that the iTunes app saves photos in a non-standard space. I believe (but it's just my guess) that Palm is advertisig that photo sync works because
    It does
    Folks who use iTunes on the Windows computer will not have to now keep track of two file locations for photos.
  6. #126  
    Quote Originally Posted by Macwinux View Post
    And that makes Palm what?
    lazy.
  7. #127  
    Following the discussion of the Apps tonight made me wonder (being a non Pre owner so hope you can enlighten me)... When you buy all these apps and you build up a library of a dozen or two or more apps... when you want to unload a few off your phone but maybe reload them back in the future, do you have the original executable or whatever they call it so that you can install it again later? Is it all put in the cloud?

    Made me think that Palm should really have created a desktop manager not only to use to sync music and photos and such and not have to rely on itunes but for Pre management like holding apps paid and unpaid.
  8. St0rmD's Avatar
    Posts
    94 Posts
    Global Posts
    97 Global Posts
    #128  
    Quote Originally Posted by donm527 View Post
    Following the discussion of the Apps tonight made me wonder (being a non Pre owner so hope you can enlighten me)... When you buy all these apps and you build up a library of a dozen or two or more apps... when you want to unload a few off your phone but maybe reload them back in the future, do you have the original executable or whatever they call it so that you can install it again later? Is it all put in the cloud?

    Made me think that Palm should really have created a desktop manager not only to use to sync music and photos and such and not have to rely on itunes but for Pre management like holding apps paid and unpaid.
    Palm doesn't "rely" on iTunes for anything. It "allows" you to natively sync your iTunes music library (and photos) to the Pre, but you can also sync those things by just mounting the phone as a usb drive and doing it by hand, or with a dozen other programs.

    All your programs and apps are automatically backed up on Palm's cloud servers. Same as your email and contacts.
    "Anyone who quotes me in their signature is an *****." -- StormD
  9. #129  
    I had a feeling you'd say that... cool in idea but I dont know if really that good in real life.

    You could be needing an app you havent used in a pinch and you have lousy signal or wont allow data at the time. Or what if you have a really big app?

    Even though you have built in Nav, what if others come out like Navagon for iPhone... That sucker is over 1GB. Games like Tiger Woods golf and football over 100MB. Pre will have larger programs as things get popular. I'd rather have a copy on my computer that I can reinstall quick.

    Quote Originally Posted by StormD View Post
    All your programs and apps are automatically backed up on Palm's cloud servers. Same as your email and contacts.
  10. #130  
    Quote Originally Posted by Macwinux View Post
    Palm has turned into a bunch of script kiddies. They can't compete with Apple on their own merits. They have to use Apple's own work to pretend they are contenders. They are still just take over bait.

    Enjoy.
    You mean, like setting up your OS so you can run Windows on a Mac? Or Microsoft Office on a Mac? Something like that?
  11. #131  
    Quote Originally Posted by s219 View Post
    I use webOS APIs and nobody is actively helping me. I use the iPhone SDK and nobody is actively helping me. If I want help, I can cash in a tech support incident with Apple and get help on anything in their realm, including that iTunes XML interface. That's how they support registered developers.
    You're going way off track here. This is not about providing technical support.

    I was saying that Apple does not make any promises to anyone about that file being there and supported. If this was an API as you and other keep calling it, that implies Apple is supporting it, documenting and guaranteeing a level of stability. My point is that Apple does not have any arrangement with anyone regarding that file. It's there for Apple's use and it can be read by others while it's there, no guarantees given. Apple can yank that file from under RIM and Nokia without any warning. So there's no difference between Palm's promise to its customers and others who work with the file regarding iTunes support.

    Nah, it's a standard XML file. I just parsed it with xmllint on the command line and it worked fine. I work with XML files for my day job, and this one is meticulously crafted and completely standard.

    Code:
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
      <dict>
        <key>Major Version</key>
        <integer>1</integer>
        <key>Minor Version</key>
        <integer>1</integer>
        <key>Application Version</key>
        <string>9.0</string>
        <key>Features</key>
        <integer>5</integer>
        <key>Show Content Ratings</key>
        <true/>
        <key>Music Folder</key>
        <string>file://localhost/Users/hsh/Music/iTunes/iTunes%20Music/</string>
        <key>Library Persistent ID</key>
        <string>4569FE9387D6212A</string>
        <key>Tracks</key>
        <dict>
          <key>583</key>
          <dict>
            <key>Track ID</key>
            <integer>583</integer>
            <key>Name</key>
            <string>Forget About It</string>
            <key>Artist</key>
            <string>Alison Krauss</string>
            <key>Album</key>
            <string>Forget About It</string>
            <key>Genre</key>
            <string>Country</string>
            <key>Kind</key>
            <string>MPEG audio file</string>
    
     etc...
    That was defined in the 90's and it shows. Nobody uses key value pairs as siblings and in an expected order. Meticulously crafted? It only passes validation.

    In the world of software development, one word we're used to dealing with a lot is "deprecated". We constantly have to come up with fixes and workarounds for stuff that is no longer supported. Or stuff that gets superseded. I'd estimate that makes up at least 20% of my job on average, sometimes more.
    You're going on a tangent here that has nothing to do with what I said.

    I'm saying that Apple does not support anyone using that file. It will not send out notifications of deprecated features, migration plans or whatever. The file is there with no guarantees whatsoever. Apple can change the file format in iTunes 10 and say nothing to anyone, it has no obligations to coordinate and maintain that file and the format used. Describing that file as a legitimate and supported API for everyone to use is baseless.

    I think you want to believe all that, but I disagree. I am pretty familiar with the Mac OSX, iPhone, and webOS (Mojo) SDKs right now, and none of them have made any promises to me. In fact, part of the agreement for the webOS SDK reads as follows:
    You're completely confused about what's being discussed here. I'm talking about publishing an API, not technical support. That means taking into account 3rd party clients using your API, attempting to keep the API stable and backward compatible and notifying clients of deprecated features and migration plans. Apple has no such relationship with anyone using the iTunes library file. RIM and Nokia promise their respective customers iTunes support based on a file they *presume* will be available to them.

    Almost every SDK agreement I have seen has some sort of section like that. Basically, you're entering into the agreement in good faith. I've never been burned in a big way, but I also have never been under any impression that there was a safety net. Software technology advances at a pretty good pace, and changes happen all the time.
    That's not the point of the discussion. When Palm provides an API developers expect documentation, stability and notification of changes and that Palm take their needs into account as best it can. Even Twitter's API which is available to pretty much anyone is officially available as such and developers expect stability and clear communication on every change for the foreseeable future. In contrast, Apple has no such relationship with anyone reading the iTunes library file.

    I don't think you understand what publishing an API means.
    Palm Vx > Treo 650 > Centro > G1 > Pre > BlackBerry 9700
  12. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #132  
    Quote Originally Posted by donm527 View Post
    I had a feeling you'd say that... cool in idea but I dont know if really that good in real life.

    You could be needing an app you havent used in a pinch and you have lousy signal or wont allow data at the time. Or what if you have a really big app?

    Even though you have built in Nav, what if others come out like Navagon for iPhone... That sucker is over 1GB. Games like Tiger Woods golf and football over 100MB. Pre will have larger programs as things get popular. I'd rather have a copy on my computer that I can reinstall quick.

    Well, the whole shift to web-based applications / programming / cloud archival sort of steers us away from large, comprehensive native-type apps anyhow. Once the app catalog gets bigger with more variety, it will be interesting to see if we actually get large apps where this is an issue.
  13. #133  
    Quote Originally Posted by donm527 View Post
    I had a feeling you'd say that... cool in idea but I dont know if really that good in real life.

    You could be needing an app you havent used in a pinch and you have lousy signal or wont allow data at the time. Or what if you have a really big app?
    ...
    And, back in the "old days", if you needed an app and weren't at your desktop, you were much in the same boat.

    Each method has pluses and minuses.
  14. #134  
    Quote Originally Posted by Really mobile View Post
    lazy.
    Or smart All the functionality of iTunes and they barely have to do anything. Why re-invent the wheel?
  15. #135  
    Quote Originally Posted by Adjei View Post
    Yeah and I guess including a hack in your own product makes it any better.
    it actually makes it a WHOLE lot better. :P
  16. #136  
    Quote Originally Posted by GMoney749 View Post
    You mean, like setting up your OS so you can run Windows on a Mac? Or Microsoft Office on a Mac? Something like that?
    huh? microsoft develops and makes $$ from office on the mac. you can run windows on the mac because they're all using x86 chips now.

    advertising dual booting was a good move, not because windows was better than OS X (that is completely laughable) but becuase MS's desktop monopoly is so strong, that was necessary to convince people that they could user computers without MS.
  17. #137  
    Quote Originally Posted by scuba_steve View Post
    My two cents:
    Palm isn't asking Apple to do anything for them. They haven't asked for an open API or even API changes. Instead, Palm had to reverse-engineer the API and then chase it. Hardly lazy.
    open source developers have figured out how to speak to ipods for years. It probably wasn't that hard for palm to look at that software and figure out how to make the pre act like an ipod.

    it WAS lazy - but that's the great thing about open source software, it allows you to leverage the work of others, and others to leverage your work. that's why android, iphone, and palm browsers all work similarly (look up webkit)
  18. #138  
    Quote Originally Posted by Hogu View Post
    advertising dual booting was a good move, not because windows was better than OS X (that is completely laughable) but becuase MS's desktop monopoly is so strong, that was necessary to convince people that they could user computers without MS.
    You don't see the parallel to what Palm is doing? You can use iTunes without having to own the dominant player on the market. I've said it before, but the Pre will not be the last device to pretend to be an iPod. The door has been opened, and Apple's only response is to update iTunes. We expect frequent updates to this new platform, but Apple can only throw so many updates out there before they start inconveniencing users.
  19. s219's Avatar
    Posts
    498 Posts
    Global Posts
    1,008 Global Posts
    #139  
    Quote Originally Posted by sivan View Post
    You're going way off track here. This is not about providing technical support.

    I was saying that Apple does not make any promises to anyone about that file being there and supported. If this was an API as you and other keep calling it, that implies Apple is supporting it, documenting and guaranteeing a level of stability. My point is that Apple does not have any arrangement with anyone regarding that file. It's there for Apple's use and it can be read by others while it's there, no guarantees given. Apple can yank that file from under RIM and Nokia without any warning. So there's no difference between Palm's promise to its customers and others who work with the file regarding iTunes support.
    You're welcome to that view, but I don't agree with it at all.

    That was defined in the 90's and it shows. Nobody uses key value pairs as siblings and in an expected order. Meticulously crafted? It only passes validation.
    Well, I don't have any problem with it at all. Since it's XML with a DTD, you don't even have to look at it to read it, or know about order, or pairing. Any objections you might have come out in the wash. As long as a document conforms to the XML spec (and key/value pairs are an accepted subset of that) then it's fair game. I think you want to object to it, but there's no reason to.

    It could be a horrendous XML document with spelling errors, curse words, **** terminology, etc, but as long as the DTD matches the document format it will work. You don't have to like or approve of their approach for it to be a perfectly workable file. I'd venture to say that most XML files I have to work with are not structured the way I'd do it, but that's not a show stopper at all.

    You're going on a tangent here that has nothing to do with what I said.

    I'm saying that Apple does not support anyone using that file. It will not send out notifications of deprecated features, migration plans or whatever. The file is there with no guarantees whatsoever. Apple can change the file format in iTunes 10 and say nothing to anyone, it has no obligations to coordinate and maintain that file and the format used. Describing that file as a legitimate and supported API for everyone to use is baseless.
    Short of deleting the file, as long as they continue using XML with a published DTD, it's supported as far as I am concerned. DTD'ed XML is self contained.



    You're completely confused about what's being discussed here. I'm talking about publishing an API, not technical support. That means taking into account 3rd party clients using your API, attempting to keep the API stable and backward compatible and notifying clients of deprecated features and migration plans. Apple has no such relationship with anyone using the iTunes library file. RIM and Nokia promise their respective customers iTunes support based on a file they *presume* will be available to them.



    That's not the point of the discussion. When Palm provides an API developers expect documentation, stability and notification of changes and that Palm take their needs into account as best it can. Even Twitter's API which is available to pretty much anyone is officially available as such and developers expect stability and clear communication on every change for the foreseeable future. In contrast, Apple has no such relationship with anyone reading the iTunes library file.

    I don't think you understand what publishing an API means.
    Well, we will have to agree to disagree here. You're spending way too much time on the API angle, when what we really have is a DTD supported XML file. The only way that is no longer useful to users is if the file and DTD are removed from circulation. To call it an API, and subject it to your own requirements for an API, is drastic overkill. DTD supported XML was created for just this reason -- it serves as it's own record.

    But overall, I am not sure what your point is. Are you trying to tell me the XML approach is no good? Would you concur that Palm's current approach is fragile and ready to break at any minute because it's not documented / supported as an API? Say what you will, but at least the XML approach is public and has self-contained documentation. As far as I am concerned, that is already a huge improvement over Palm's current tack.
  20. #140  
    Quote Originally Posted by Hogu View Post
    huh? microsoft develops and makes $$ from office on the mac. you can run windows on the mac because they're all using x86 chips now.

    advertising dual booting was a good move, not because windows was better than OS X (that is completely laughable) but becuase MS's desktop monopoly is so strong, that was necessary to convince people that they could user computers without MS.
    "Better" and whether or not it was a "good move" are not germane to the point being made.

    Apple is implementing and advertising compatability with software developed by Microsoft in order to sell their hardware. Substitute names in that sentence and see if you still think it's a "good move".
Page 7 of 11 FirstFirst ... 234567891011 LastLast

Posting Permissions