Subject:
|
Re: Planes for a new download-tool (2)
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Fri, 21 Jul 2000 04:53:45 GMT
|
Viewed:
|
932 times
|
| |
|
|
What I can tell you is that the http code will run on Windows if you used
sockets for the communication.
However designing an interface in Unix and Windows is totaly different, and
this most of the tool if believe.
Another possibility is to use Java (but I don't know if that thing can work
with sockets ... just there is nothing for ftp, http specially) this would
be portable enough.
But we could try to find a common solution for all of us in form of a
library which handles downloading, contains the logic what to download ...
Finding file-time-stamps on Windows will not work as it does on Unix by the
way!
The GUI stuff would have to be written seperatly for each thing.
The advantige of MFC on Windows is that e.g. downloading a file via http are
4 lines of code if you use MFC!!!! Thats much easier than using sockets ...
but I do not mind having something portable inside a tool
Michael
Travis Cobbs <tcobbs@san.REMOVE.rr.com> schrieb in im Newsbeitrag:
Fy0H3r.MIx@lugnet.com...
> Sorry, I guess my previous post may have been a little misleading. The
> program I am working on (haven't done much with it in the last couple of
> months, actually), is a general-purpose http download program. It wasn't
> actually set up to do anything ldraw-specific.
>
> It has ability to parse an html page and download all the files linked • from
> the page which have been updated since a certain date. It also supports
> following links to other html files and repeating the process (which could
> get out of hand rather quickly unless certain restrictions are put in
> place). The idea when I was working on it was to simply track the last
> successful run date, and then grab everything which had updated since • then.
> The version I have actually uses the date that it fetches from the http
> header (which requires an http connection). It could be modified to parse • a
> specialized index which included dates.
>
> It's currently a console app (no UI). Given that all the downloading
> happens in background threads, it could presumably have a UI attached
> relatively easily. In fact, if the current foreground thread (which
> controls the others) were itself made into a background thread, it would • be
> even cleaner.
>
> However, before we decide to add a UI to what I have, we should decide
> whether the Windows and Unix versions will have enough in common to be a
> single project with OS-specific UI and http sections, or whether they • should
> be completely separate. I would hope that it would make more sense to • have
> a single project. If so, though, the raw http code I have would probably • be
> more useful than the rest.
>
> In any event I'm leaving for a week vaction on Saturday, so I won't be
> around to answer further questions until I get back.
>
> --Travis Cobbs (tcobbs@san.REMOVE.rr.com)
> (Remove .REMOVE from address to send me e-mail.)
>
> "Michael Lachmann" <m.lachmann@xpoint.at> wrote in message
> news:FxzB6H.2Lr@lugnet.com...
> > Yes sure I'm interested ... in the mean time I did the same for Windows • and
> > it worked fine ... so it seems we both solved the question of how to • work
> > with http .... but have you build in some logic already (what to • download
> > ... if it's up-to-date)?
> >
> > By the way if someone is interested in that source as well just drop me • note
> > ...
> >
> > Michael
> >
> >
> > Travis Cobbs <tcobbs@san.REMOVE.rr.com> schrieb in im Newsbeitrag:
> > FxyHwu.As3@lugnet.com...
> > > In a previous post, you asked about portability to Unix. I am writing • a
> > > multi-threaded http download program in Linux. The back end http • stuff
> > > already works fine. It shouldn't be too difficult for me to make it • generic
> > > enough for general consumption.
> > >
> > > Getting it to run in Windows would be significantly harder, though, • since
> > it
> > > uses socket stuff which has not been set up to run in Windows (not TOO • hard
> > > to fix) as well as POSIX threads (very hard to fix, unless I am badly
> > > mistaken). Let me know if you're interested. It's written in C++, by • the
> > > way.
> > >
> > > Before anyone asks, the reason it's multi-threaded is because with a • cable
> > > modem you can get significant download performance gains by do • multiple
> > > simultaneous downloads.
> > >
> > > --Travis Cobbs (tcobbs@san.REMOVE.rr.com)
> > > (Remove .REMOVE from address to send me e-mail.)
> > >
> > >
> > >
> >
> >
>
>
|
|
Message has 2 Replies:
 | | Re: Planes for a new download-tool (2)
|
| (...) Actually it can, and it's also a lot easyer, since there are already made packages for each of those protocols. (...) That depends, I think there is a compatibility lib, provided with VC++, at least, which allows to know the file state (...) (24 years ago, 24-Jul-00, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: Planes for a new download-tool (2)
|
| Sorry, I guess my previous post may have been a little misleading. The program I am working on (haven't done much with it in the last couple of months, actually), is a general-purpose http download program. It wasn't actually set up to do anything (...) (24 years ago, 20-Jul-00, to lugnet.cad.dev)
|
24 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
