Windows Desktop APP to find emails and input forms in websites
Budget: $50 – $150 USD
I would like a windows 10 desktop application whose input is a list of URLs and whose output is the email addresses, input forms and text from the home page found within the URL and following links limited according to the parameters below.
Before we talk, you have to tell me the smallest prime number greater than seven.
The only interactions between the user and the application:
1. The user has a procedure to hardcode the name of a file directory within the application that will be used. The application is recreated with the given directory name embedded in it.
2. If the above file directory cannot be found when the application is run, the application will display the file directory name and an error message.
All other communication is done through files read and created by the application within the above directory.
By URL I will mean the URLs that are input. By PAGE I will mean the URLs and all pages that are traversed starting at the input URLs.
INPUT
The hardcoded directory will have a text file INPUT.txt which contains its parameters and URLs as follows. In (5) and (6) N means a single digit 0 to 9.
1. Maximum depth to search each URL.
Examples: 1 means search the URL page only. 2 means search the URL and those pages it links directly to.
2. Maximum number of pages to examine per URL.
3. Maximum number of emails to retrieve per URL (skip extras).
4. Maximum number of input forms to retrieve per URL (skip extras).
5. Number of seconds (0 or N.N) to pause between URLs.
6. Number of seconds (0 or N.N) to pause between pages after the URL is accessed.
7. The list of URLs to process.
OUTPUT
The app will create the following files in the hardcoded directory. Start-of-the-art methods should be used to access as much data as available, including the use of subscriptions.
START.txt = The time the application started
END.txt =
1. The time the application ended
2. The number of URLs accessed
3. The number of URLs that could not be accessed
ERRORS.txt = Errors preventing the app from running. Examples:
1. File INPUT.txt not found.
2. Errors in items 1-6 in INPUT.txt.
DATA#.txt = DATA1.txt, DATA2.txt etc. with the emails, input forms and URL text found in the list of URLs.
DATA1.txt will contain the data from the 1st 10 URLs. DATA2.txt will contain the data from the 11th to 20th URL etc.
The data from each URL will be as follows:
1. Time (year, month, day, hour, minute, second) the processing of that URL ended.
2. Number of Pages examined.
3. The maximum page depth reached (1 = the given URL).
4. Reason for stopping:
completed URL, maximum pages reached, maximum depth completed, maximum emails and input forms reached.
5. The text on the URL (home page.)
6. For each email retrieved (skip duplicates within this URL):
a. Email address
b. Text displayed with the email address
c. Page Link on which the email was found.
7. For each input form retrieved:
a. Page Link on which the form was found.
b. For each input: Type of Input (text, radio etc.), Text displayed, Literal choices to choose from.
SUPPORT
1. Source Code
2. User manual
3. Programmer manual
a. Technologies used
b. Overall flowchart
c. Each Subroutine/Function defined: name, inputs, outputs, relationship between inputs and outputs
4. Bug fixes: Free period (restarts when a bug is fixed), future agreement.
5. Installation & processing issues.
I have left the formats of files up to you. In general, all delimiters should be control characters and begin with line feed between records (URLs, Emails, Forms) then tab character between fields within a record. Single fields (e.g. date) have readable delimiters if they have multiple parts.
Feel free to suggest specification changes that make more sense to you.
Charlie
Before we talk, you have to tell me the smallest prime number greater than seven.
The only interactions between the user and the application:
1. The user has a procedure to hardcode the name of a file directory within the application that will be used. The application is recreated with the given directory name embedded in it.
2. If the above file directory cannot be found when the application is run, the application will display the file directory name and an error message.
All other communication is done through files read and created by the application within the above directory.
By URL I will mean the URLs that are input. By PAGE I will mean the URLs and all pages that are traversed starting at the input URLs.
INPUT
The hardcoded directory will have a text file INPUT.txt which contains its parameters and URLs as follows. In (5) and (6) N means a single digit 0 to 9.
1. Maximum depth to search each URL.
Examples: 1 means search the URL page only. 2 means search the URL and those pages it links directly to.
2. Maximum number of pages to examine per URL.
3. Maximum number of emails to retrieve per URL (skip extras).
4. Maximum number of input forms to retrieve per URL (skip extras).
5. Number of seconds (0 or N.N) to pause between URLs.
6. Number of seconds (0 or N.N) to pause between pages after the URL is accessed.
7. The list of URLs to process.
OUTPUT
The app will create the following files in the hardcoded directory. Start-of-the-art methods should be used to access as much data as available, including the use of subscriptions.
START.txt = The time the application started
END.txt =
1. The time the application ended
2. The number of URLs accessed
3. The number of URLs that could not be accessed
ERRORS.txt = Errors preventing the app from running. Examples:
1. File INPUT.txt not found.
2. Errors in items 1-6 in INPUT.txt.
DATA#.txt = DATA1.txt, DATA2.txt etc. with the emails, input forms and URL text found in the list of URLs.
DATA1.txt will contain the data from the 1st 10 URLs. DATA2.txt will contain the data from the 11th to 20th URL etc.
The data from each URL will be as follows:
1. Time (year, month, day, hour, minute, second) the processing of that URL ended.
2. Number of Pages examined.
3. The maximum page depth reached (1 = the given URL).
4. Reason for stopping:
completed URL, maximum pages reached, maximum depth completed, maximum emails and input forms reached.
5. The text on the URL (home page.)
6. For each email retrieved (skip duplicates within this URL):
a. Email address
b. Text displayed with the email address
c. Page Link on which the email was found.
7. For each input form retrieved:
a. Page Link on which the form was found.
b. For each input: Type of Input (text, radio etc.), Text displayed, Literal choices to choose from.
SUPPORT
1. Source Code
2. User manual
3. Programmer manual
a. Technologies used
b. Overall flowchart
c. Each Subroutine/Function defined: name, inputs, outputs, relationship between inputs and outputs
4. Bug fixes: Free period (restarts when a bug is fixed), future agreement.
5. Installation & processing issues.
I have left the formats of files up to you. In general, all delimiters should be control characters and begin with line feed between records (URLs, Emails, Forms) then tab character between fields within a record. Single fields (e.g. date) have readable delimiters if they have multiple parts.
Feel free to suggest specification changes that make more sense to you.
Charlie