On Tue, Jul 22, 2003 at 06:24:52PM -0400, Keith M. Hughes wrote: > Which I am. Willing to code it, that is. I just wanted to make sure > there was nothing existing yet. Adam's package using ATP sounds like it > would work, but I don't know enough about ATP to know if this solution > would have a big footprint on the Palm and overkill for my situation.
Well, porting *all* of apt's features to the palm would be overkill and unnecessary. My thoughts were to port over the basic idea behind apt: 1. The user adds on multiple sources onto their device that in turn act as repositories of packages (packages being a collection of one or many .pdb/.prc's plus a setup script if need necessary) 2. The user hotsync's once to download a list of what is available at that source including package title, update frequency, description, supported devices, etc 3. The user goes through the main list of what is available, and places a checkbox beside the packages they want (for example, CNN, CBC, BBC, but not ABC or CTV for example, but all five are available from one source) 4. The next hotsync automagically downloads those packages and installs them transparently. Then, for each subsequent hotsync the prog would re-check the source to see if any new versions have been released (ie, the document has been updated) and downloads it automatically. As well, if the user decides, that they no longer care for CNN they would uncheck it and the unpackaged CNN data is removed from their device. The cool thing is though that this wouldn't be limited to plucker documents. One could release entire software suites as a 'package' so the user will always have the latest released version of a program. As well, Palm could utilize such a medium to auto-distrobute patches for your device, since packages could be made to be device aware, os version aware, available RAM aware... anything :P > A customized solution would just delete all content associated with > a given Plucker document and download the new content might be much > smaller and more efficient for most users. But certainly Adam's would > mean you have one content management system as opposed to a customized > one for everything. Exactly. Ofcourse getting third party developers to use it might be difficult, but atleast for home-only use it would be very easy as all you require is an http/ftp server. Cronjob/scheduled event to pluck from home, hotsync at work.. bingo, the latest plucker docs on your device at all times :) > I could be completely wrong about this, so please tell me if I am > mistaken. If people have to download the Plucker desktop, that is a big > download, what with Python and everything. It is just a one-time thing, > but that one-time cost keeps some people from installing software. In theory the user would only need the python/desktop/jpluck if they wanted to actually create pdbs with their own content. However, if the user only cares for the viewer and pre-built content, then technically all the end-user would need is the apt-palm.prc and a server.pdb describing a repository and pre-checked packages. The plucker viewer itself could even be distrobuted/updated/released using only these two files. Note BTW that I'm planning on setting it up so that each source a user adds will create a unique .pdb on their device with the selected packages defined within. That way content/application owners can say to their users, "Download this apt-palm program and this .pdb, and instantly you'll have the latest version of my software installed on your palm, plus any new releases will be automatically downloaded!" Ofcourse, like debian's apt if an earlier version of a program is better than a later one, end-users can freeze installed packages to keep the existing copies but ignore any newer releases. > Especially if they are on a dialup connection. And, if they are on a > dialup connection, it would be nice to download their content in a > compressed form so they don't tie up their phone line for a long time > downloading the original and then distilling it client side. ZLib :) The only problem with that is uncompressing and installing requires almost atleast twice the free space available on the device before you can do anything. I havn't worked much on this problem yet :) > I don't think having conduits for downloading specified content also > precludes someone from using the distiller on their machine. It just > means that they are getting some of their content faster. > > Also, a step gets cut out for users who don't revel in having complete > flexibility in everything they do. A quicker learning curve (just the > Plucker app, rather than the app and the desktop) means they can more > quickly use the app, fall in love with it, and then decide to do that > huge download to get the desktop and distiller. Exactly :) -- Adam McDaniel Array.org Calgary, AB, Canada _______________________________________________ plucker-dev mailing list [EMAIL PROTECTED] http://lists.rubberchicken.org/mailman/listinfo/plucker-dev
