[REBOL] Re: [REBOL.org] [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: [REBOL.org] [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 rebol.org
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 rebol.org (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
