Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: [] [ANN] Packages: the next generation

From: maximo:meteorstudios at: 4-May-2004 11:52

> -----Original Message----- > From: [SunandaDH--aol--com] [mailto:[SunandaDH--aol--com]] > Sent: Tuesday, May 04, 2004 5:05 AM > To: [rebol-list--rebol--com] > Subject: [REBOL] Re: [] [ANN] Packages: the next generation > > > *The descriptions, "package file", "linked script", > > "package script", "script from Library" look like > >they could be useful, but to me I'm not sure > > what they actually mean. > "package file" -- is a file in the package that the package owner has > uploaded. It may be a REBOL script, binary image or anything else
linked script is as sunanda described, a script already on package file is if the author included a package. as described in my quick start repack mail, recursive downloading, is not yet available, just download it by iteslf (in the proper directory). script from Library !?!? ahhhh yeah, I see, (after looking at steel-libs package)... those are the notes under the file info... yes, maybe the LDS server should get the notes or purpose details from the linked script itself... as it is now, that is a generic message for linked scripts... Sunanda what do yo think, is that complex to do?
Perhaps a link to a glossary of
> terms or help page would be good.
part of the eventual help mentioned below...
> there is only ever > one copy of values.r in the Library -- not dozens of copies > in different > packages.
this of course depends if you install packages in their own directories, in which linked scripts DO exist in every install. Slim (from the steel project) would allow only one copy of the file to exist for all apps, even if the apps where installed anywhere.
> > *It was not obvious to me that clicking on an item in the > > package pane would > > invoke network activity. This could be important for > > someone on a slow link.
I built the application solely on a 56k access... its not too bad, waiting 1 second for the feedback, but It could be made clearer or it could also be buffered, so that if you go back to an earlier package, it does not upload it again. I thought maybe making the network feedback a distinct color (like blue)... maybe a first time use pop-up could also be usefull... (with "do not ask again" check box)
> > The subtle psychological consequence is that a user could > become worried > > that they don't know when and where to click to be most efficient.
There are only three buttons which poke the network. 1- refresh in package pane 2- clicking on a package to get its specs 3- download button all the rest is memory and disk access.
> More visual feedback on what is happening is on the list of > things to do. > > I agree that on slow links no one wants a program to start > unexpectedly to > start long-running network operations (I got only a 56K modem > link most of the > time myself).
but at least in (now released) v1.1.0 you do get much better message & logging and a real "stop!" button to cancel downloads. docs are definitely missing at this point... the next version (no estimated release) will have a help button with descriptive text AND images.
> But total data transfer is very small -- well under 2K in > most cases, unless > you actually click the download button.
yep! network demands are pretty compact. I'd say (through repack.r) bogs down only about 1-2% of requests (i.e. a network operation would take 10-15 seconds to complete, due to server/internet load)... btw which version did you try? HTH! -MAx