2.04 GB of Downloads: Another call for selective downloads please

JimTowler

Well, this 2 GB is a vary large portion of the download limits for most users in this country!!

Another call for selective download controls please.

One messy and really ugly workaround is:

1) Download and print the Release Notes for the Resource Update

2) Identify and HIDE some of the larger and low-priority resources

3) Restart a few times to make sure they are hidden, then begin the download

4) Allow reindex etc to complete

5) Un-hide the larger resources one or two at a time, over as many days as desired, to manage the download sizes and traffic usage.

YUCK!

Please can we have a better way?

Find more posts tagged with

Comments

Terry Poperszky

Way to think outside of the box Jim!

NetworkGeek

I think Bob has posted on here, that Logos managing the different versions of files, and different states of current version that users' systems would be in would be untenable from a support perspective, which has cost and quality considerations. Given how closely the resources and the versions are tied for some functions, when Logos can no longer count on there not being a mismatch, maintaining any kind of consistent quality becomes quite problematic.

Just relaying this on because it has been discussed often - please don't shoot the messenger [A]

MJ. Smith

Please can we have a better way?

Jim, I agree that a better way needs to be available for people with download limits. While your solution isn't the ideal, I think you should put it on the wiki as a temporary work-around. At least it gives users their most important resources before they hit their limits. You may even put a Mr. Yuck face on it, if it suits your humor.

Seattle is not only the "birth place" of grunge. It is also the birth place of Mr. Yuck. PS he is not to be abused, he labels things as poison/hazardous for children.

JimTowler

Yes, no shooting.

I've heard this view on why we can't have selective downloads before, but I don't consider that an acceptable "solution", for customers with limited Internet traffic-caps or usage surcharges.

NOT all updates are created equal. It would be an easy matter to put any resource updates into 2 or 3 types:

A) Application updates and critical resource updates to prevent crashes or major fault conditions. If a resource is rebuilt with a critical change to its internal format, and the application would be unstable without this update, its an (A)!

Major update to a resource. If you use this resource, you really "need" this update. Maybe a major re-page, re-index or otherwise a "big deal".

C) Minor typos or lesser changes. You may want this, but it many be a low priority for you.

If a user elects to NOT take the (B) or (C) updates, it does NOT create application crashes, support issues or nighmares.

It would be easy for something to be added to the metadata for resources, by build-version, so there was some visual clue somewhere, that a given resource has outstanding (B) or (C) updates that can be downloaded.

I might be happy to have outstanding typos in some resources I hardly or never use, until I'm at a place or time, that the download and reindex is acceptable.

Any time Logos releases an updated resource, they would tag it as (A), (B) or (C) and make a comment in the release notes too.

(After 1.5 hours, I'm at 9% of my 2 GB downloads ... Internet is NOT unlimited size or speed here)

JimTowler

Jim, I agree that a better way needs to be available for people with download limits. While your solution isn't the ideal ...

YES - far from ideal. Others can decide if hiding some of their larger but less-important resources has much merit. It would be easier if the release-notes had file sizes too.

Of the 2 GB, it seems 600 MB of this is the two Greek audio resources (Pronunciation), so I can't hide them anyway. Besides, I often use the Erasmian one. Maybe I'd hide the "Modern" one if I could.

Eric Ruhnow

Could we maybe have a "forked" install choice (thinking along the Ubuntu release view: rare hard-core STABLE releases and more frequent "minor" updates).

We already have the Beta and Stable channels. Maybe Logos could add 6 month channel as well, for those who need the underlying stability enhancements to the engine without needing all the "extras" that make updates like this one hard on those with limited connection issues.

Just my 2c.

JimTowler

Interesting idea ...

Actually, I don't think the problem here is the update to the Logos4 application itself. Its only small.

Given that everyone was going to need a full reindex anyway, maybe Logos decided to release some pending resource updates at the same time.

P.S. Of my 2 GB download, I have an estimated 500 MB still to go, after some 6 hours already spent on the download. Indexing still future. NOT a light impact on resources.

David Ames

RE: Jim T and his A, B, C updates

You call support - First Question - Did you update all the 'A' updates - if not please call back after updating

You call support on Resource 'XYZ' - first question - Did you update the 'B' update on that resource - if not please call back after updating

They might also inform you of interactions of other 'B' updates on Resource 'XYZ' [Resource 'XYZ' is up to date but it requires 'ABC' to work correctly]

Or LOGOS could just break up the updates into 100 MB chunks - Laptop done and now to do the Desktop

David Ames

RE: Jim T and his A, B, C updates

You call support - First Question - Did you update all the 'A' updates - if not please call back after updating

You call support on Resource 'XYZ' - first question - Did you update the 'B' update on that resource - if not please call back after updating

They might also inform you of interactions of other 'B' updates on Resource 'XYZ' [Resource 'XYZ' is up to date but it requires 'ABC' to work correctly]

Or LOGOS could just break up the updates into 100 MB chunks - Laptop done and now to do the Desktop

Bob Pritchett

Sorry I'm so late to this. :-)

Fortunately, several people have already stepped in to make my point: it's logistically impossible for us to "hold some of your calls." We are, in fact, trying to hold "typo" updates, and almost everything we are pushing out is in the A) or categories -- things that need to be kept in sync with the app.

The biggest things are generally the media resources (some of which have been updated since we shipped in order to correct important metadata errors -- this format was new to Logos 4 and we learned some things along the way) and reverse interlinears, which touch everything. It would be difficult to code the app to not crash if everyone ran different versions of the very-integral reverse interlinears.

We've been updating the rev int's because you asked for it: full-screen reverse interlinear display (which we never planned, but did in response to user requests), and then revising the database with extra fields/info to implement requested features and enhancements.

Now it's true you could argue we should have held the product, tested all of this thoroughly, gotten more user feedback before shipping, etc. That would just have taken, um, about as long as it's taken... because we've just kept working hard on it. This gets back to the many-times-argued discussion we've had in the forums: should we have held Logos 4 or shipped it? And, as I've pointed out (with no malice intended) you can choose that "hold it till it's perfect!" scenario right now by simply continuing to use Logos 3 for another six months or so. (Yes, I understand that might make you upset -- that we dared to ship short of perfection -- but I've got as many or more users on the other side who wanted it out there, and are happy with it now.)

I imagine that soon after the next major release (which should have almost all the "missing features" of Logos 3) you'll find that resource updates slow down dramatically. I find them annoying, too, but hope you realize they just mean you're getting a constantly improved product!

As for solutions: we aren't going to let you pick and choose, for all the reasons exhaustively given. It really is logistically impossible. There is hope: patching. Google Chrome and other "updated all the time" apps send down patch files that represent just the differences between version 34 and version 35 of a file. Then code runs on your machine to turn your copy of v34 into v35.

The problem is, somebody out there had the Internet turned off since v23. So they need the v23 -> v35 patch. Or the v1 -> v35 patch, which could be bigger than v35.

And while Chrome has "one app" to update, we've got 10,000+ individual resources.

I think there are solutions, and there are "off-the-shelf" solutions, extensively tested over many years, that can help with this scary-complex process. But it's still a lot more complicated than delivering the latest file, and introduces many more potential failure/corruption points.

There's also the question of the best use of our coding resources: do you want printing first, or patching? Especially since it's like that this year we'll grow out of the frequent updates phase, and things should stabilize.

JimTowler

Thanks Bob,

As the one that started this thread, thankyou for taking the time again to reply.

- Jim

MJ. Smith

There's also the question of the best use of our coding resources

Well I certainly have my opinions but they're just not happening - lectionaries, early translations such as the Gothic, Anglo-Saxon, Armenian, notes linked to multiple passages ... [:D]Seriously, while I've had to wait for some of the things that matter most to me, I think Logos has generally done a good job of prioritizing features. One of the things that continues to surprise me on the forums is the degree to which users fail to understand that in order for them to get their No. 1 priority, someone else's No. 1 priority is delayed. We can't all get it now ... although at least I am perfectly capable of wanting it all now. Thanks for taking the time to reply.