U.S. patent application number 13/074328 was filed with the patent office on 2011-07-21 for method of reflecting on another device a change to a browser cache on a handheld electronic device, and assocaited device.
This patent application is currently assigned to Research In Motion Limited. Invention is credited to Yu Tang, Daniel Van Geest.
Application Number | 20110179138 13/074328 |
Document ID | / |
Family ID | 38750772 |
Filed Date | 2011-07-21 |
United States Patent
Application |
20110179138 |
Kind Code |
A1 |
Van Geest; Daniel ; et
al. |
July 21, 2011 |
METHOD OF REFLECTING ON ANOTHER DEVICE A CHANGE TO A BROWSER CACHE
ON A HANDHELD ELECTRONIC DEVICE, AND ASSOCAITED DEVICE
Abstract
An improved handheld electronic device includes an Application
Programming Interface (API) that generates various notifications in
certain circumstances. The handheld electronic device provides an
improved method of employing the notifications to enable another
device to reflect a change to a browser cache on the handheld
electronic device.
Inventors: |
Van Geest; Daniel; (US)
; Tang; Yu; (US) |
Assignee: |
Research In Motion Limited
|
Family ID: |
38750772 |
Appl. No.: |
13/074328 |
Filed: |
March 29, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11414785 |
Apr 28, 2006 |
7937361 |
|
|
13074328 |
|
|
|
|
Current U.S.
Class: |
709/217 |
Current CPC
Class: |
H04L 67/18 20130101;
H04L 67/04 20130101; H04L 67/1095 20130101; G06F 16/9574 20190101;
H04L 67/06 20130101 |
Class at
Publication: |
709/217 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. At a server of mobile communications devices, a method of
servicing requests for HTML documents, said HTML documents
containing a plurality of HTML objects, from mobile communications
devices, said method comprising: upon initiation of a browser
session at a given mobile communications device served by said
server, receiving at least a portion of a copy of a mobile data
table stored on said given mobile communications device, said
mobile data table comprising (i) a filename of an HTML object, (ii)
an associated URL of a location from which said associated HTML
object was obtained, and (iii) an associated expiry date, so as to
indicate the contents of a browser cache of HTML objects at said
mobile communications device; reflecting said mobile data table in
a server data table for said given mobile communications device;
thereafter, receiving updates from said given mobile communications
device of changes to said browser cache such that said server data
table is maintained as a mirror of said mobile data table; upon
receiving a request for an HTML document from said given mobile
communications device, determining from said server data table
whether HTML objects contained in said requested HTML document are
present in said browser cache; and sending a copy of a particular
HTML object to said given mobile communications device when said
determining determines that said particular HTML object is not
present in said browser cache; and sending an update to said given
mobile communications device when said determining determines that
said particular HTML object is present in said browser cache in an
expired state.
2. The method of claim 1 wherein said sending an update to said
given mobile communications device comprises requesting a new copy
of said particular HTML object from a location indicated by an
associated URL stored in said server data table for said HTML
object only if said particular HTML object has changed since a
given time wherein said given time is indicated by an associated
expiry date of said particular HTML object stored in said server
data table.
3. The method of claim 2 further comprising sending an updated
expiry date of said particular HTML object to said given mobile
data communications device when said HTML object has not
changed.
4. The method of claim 2 further comprising sending (i) said new
copy of said particular HTML object to said given mobile data
communications device when said HTML object has changed, and (ii)
an expiry date of said new HTML object.
5. The method of claim 1 wherein said receiving updates comprises
receiving from said given mobile communications device (i) a CREATE
notification and (ii) at least a representation of a URL associated
with said created HTML object.
6. The method of claim 1 wherein said receiving updates comprises
receiving from said given mobile communications device (i) a DELETE
notification for a particular HTML object and (ii) at least a
representation of a URL associated with said deleted HTML
object.
7. The method of claim 1 wherein said receiving updates comprises
receiving from said given mobile communications device (i) a RENAME
notification for a particular HTML object and (ii) an indicator of
the new name of said renamed particular HTML object.
8. A method of processing HTML documents at a mobile communications
device during a browser session, said browser session including
communication with a server servicing requests from said mobile
communications device for HTML documents, said method comprising:
maintaining a browser cache of HTML documents at said mobile
communications device; maintaining a mobile data table at said
mobile communications device comprising a plurality of records,
each record comprising (i) a filename of an HTML object in said
browser cache, (ii) an associated URL of a location from which said
associated HTML object was obtained, and (iii) an associated expiry
date; upon initiation of said browser session providing at least a
portion of a copy of said mobile data table to said server;
detecting that a particular HTML object in said browser cache has
undergone a change; responsive to said detecting, sending an update
to said server, said update comprising a filename of said
particular HTML object and an indicator of the nature of said
change, whereby said mobile data table is mirrored at said
server.
9. The method of claim 8 wherein said detecting comprises detecting
that said particular HTML object has been deleted and wherein said
method further comprises deleting the mobile data table record
associated with said HTML object.
10. The method of claim 9 wherein said sending an update to said
server comprises sending at least a representation of a URL
associated with said deleted HTML object and a DELETE
indicator.
11. The method of claim 10 wherein said representation of a URL is
a hash representation of said URL.
12. The method of claim 8 wherein said detecting comprises
detecting that said particular HTML object has been updated and
wherein said method further comprises updating the mobile data
table record associated with said HTML object with an updated
expiry date.
13. The method of claim 12 wherein said sending an update to said
server comprises sending at least a representation of a URL
associated with said updated HTML object, an UPDATE indicator and
an expiry date.
14. The method of claim 12 wherein said detecting that said
particular HTML object has been updated comprises receiving an
UPDATE notification from said server.
15. The method of claim 13 wherein said representation of a URL is
a hash representation of said URL.
16. The method of claim 8 wherein said detecting comprises
detecting that said particular HTML object has been renamed and
wherein said method further comprises updating the mobile data
table record associated with said HTML object with a new name.
17. The method of claim 16 wherein said sending an update to said
server comprises sending at least a representation of a URL
associated with said renamed HTML object and a RENAME indicator and
an indicator.
18. The method of claim 17 wherein said representation of a URL is
a hash representation of said URL.
19. The method of claim 8 further comprising detecting that a new
HTML object has been added to said browser cache and creating a new
record in said mobile data table associated with said new HTML
object.
20. The method of claim 19 further comprising providing at least a
portion of said new record to said server, said new record at least
including a representation of a URL associated with said new HTML
object.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application is a continuation of application Ser. No.
11/414,785 filed on Apr. 28, 2006, the contents of which are hereby
incorporated herein by reference.
BACKGROUND
[0002] 1. Technical Field
[0003] The disclosed and claimed concept relates generally to
handheld electronic devices and, more particularly, to a method of
reflecting on another device a change to a browser cache on a
handheld electronic device.
[0004] 2. Description of the Related Art
[0005] Numerous types of handheld electronic devices are known.
Examples of handheld electronic devices include, for instance,
personal data assistants (PDAs), handheld computers, two-way
pagers, cellular telephones, and the like. Many handheld electronic
devices also feature a wireless communication capability, although
many such handheld electronic devices are stand-alone devices that
are functional without communication with other devices.
[0006] Some handheld electronic devices that are sold with certain
software resident thereon and are configured to allow additional
software developed by third parties to be installed and executed on
the electronic handheld device. In order to facilitate the use of
such third-party software, the manufacturer of the device may sell
the device with original software that is sufficiently versatile to
enable cooperation between the original software and third-party
software. Such third-party software may be provided on the device
when originally provided to a consumer, or may be added after
purchase. While such handheld electronic devices and software have
been generally effective for their intended purposes, such handheld
electronic devices have not been without limitation.
[0007] For instance, the original software provided by a
manufacturer may be configured to be so versatile as to be somewhat
burdensome to use. For example, the original software may provide a
routine such as an Application Programming Interface (API) that
third-party software can employ to receive notifications in
response to certain events on the handheld electronic device. Due
to the intended versatility of the original software, the original
software may provide many more notifications than are needed or are
usable by the third-party software. The processing of so many
unnecessary notifications undesirably adds processing overhead and
consumes both processing and power resources. Moreover, despite
their versatility, such APIs may still provide fewer than all of
the functions that might be desirable for use with certain
third-party software. For instance, the API may provide certain
notifications, but such notifications may provide less than all of
the data that would be desirable for proper operation of the
third-party software.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] A further understanding of the disclosed and claimed concept
can be obtained from the following Description when read in
conjunction with the accompanying drawings in which:
[0009] FIG. 1 is a schematic depiction of an improved handheld
electronic device in accordance with the disclosed and claimed
concept in communication with a network;
[0010] FIG. 2 is a schematic depiction of a portion of a memory on
the handheld electronic device of FIG. 1;
[0011] FIG. 3 is an exemplary flowchart of at least a portion of an
improved method that can be performed on the improved handheld
electronic device of FIG. 1; and
[0012] FIG. 4 is an exemplary flowchart of at least a portion of
another method that can be performed on the improved handheld
electronic device of FIG. 1.
[0013] Similar numerals refer to similar parts throughout the
specification.
DESCRIPTION
[0014] An improved handheld electronic device 4 is depicted
schematically in FIG. 1 as being in communication with a network 8.
The exemplary network 8 enables communication between it and the
handheld electronic device 4 via an antenna 10 that is connected
through the network 8 with a server 12. The exemplary network 8
communicates wirelessly with the handheld electronic device 4,
although it is understood that the network 8 could have a wired
connection with the handheld electronic device 4 without departing
from the present concept.
[0015] The exemplary handheld electronic device 4 comprises an
input apparatus 16, a processor apparatus 20, and an output
apparatus 24. The processor apparatus 20 is configured to process
input received from the input apparatus 16 and to provide output to
the output apparatus 24.
[0016] The processor apparatus 20 comprises a processor and a
memory 28. While not expressly depicted herein, it is understood
that the processor could be any of a wide variety of processors,
such as a microprocessor (.mu.P) that is responsive to input from
the input apparatus 16, that provides output to the output
apparatus 24, and that interfaces with the memory 28.
[0017] The memory 28 is depicted schematically in FIG. 2. The
memory 28 can be any of a variety of types of internal and/or
external storage media such as, without limitation, RAM, ROM,
EPROM(s), EEPROM(s), and the like that provide a storage register
for data such as in the fashion of an internal storage area of a
computer, and can be volatile memory or nonvolatile memory. The
memory 28 additionally includes a number of routines stored therein
that are executable on the processor, as will be set forth below in
greater detail. As employed herein the expression "a number of" and
variations thereof shall refer broadly to any nonzero quantity,
including a quantity of one. The routines can be in any of a
variety of forms such as, without limitation, software, firmware,
and the like.
[0018] The memory 28 comprises a browser cache 32 having a number
of files 36 stored therein within a directory structure. Each file
36 in the browser cache 32 has a file name 40 and has stored
therein, for example, an object 44, a location from where the
object 44 was obtained, such as a Uniform Resource Locator (URL)
48, and an expiry date 52 for the object 44. Additional relevant
information may be stored in each file without departing from the
present concept.
[0019] The memory 28 additionally has stored therein an operating
system 56, an API 60, and a browser routine 64, among other
routines as mentioned above. As is understood in the relevant art,
the browser routine 64 is operable to obtain and process various
items such as HyperText Markup Language (HTML) documents. A given
HTML document may comprise, for example, text, and may additionally
comprise descriptions of locations where additional objects may be
obtained and which are to be inserted into the text. Exemplary
objects that are insertable into text would include images,
executable code such as JavaScript, and other objects. If an HTML
document that is being processed by the browser routine 64
comprises one or more locations, the objects stored at such
locations must be obtained in one fashion or another for inclusion
in the output that results from the such processing of the HTML
document. The locations may, for example, be URLs on a network such
as the Internet.
[0020] In order to reduce communication bandwidth, such as a
bandwidth of the wireless communication enabled between the
handheld electronic device 4 and the network 8, certain of the
needed objects may be stored, i.e., saved, in the browser cache 32
as objects 44 stored within the files 36. For example, if an HTML
document being processed by the browser routine 64 comprises a
location such as a URL 48 in one of the files 36, and if the expiry
date 52 of the object 44 in the file 36 has not been exceeded, the
object 44 stored in the file 36 is retrieved from within the
browser cache 32 and is provided to the browser routine 64 for
inclusion in the HTML document. In such a fashion, the amount of
communication traffic between handheld electronic device 4 and the
network 8 can be reduced.
[0021] One exemplary implementation of such a browser cache 32 on
the handheld electronic device 4 would additionally include storing
on the server 12 or otherwise making available to the server 12 a
mirror of the browser cache 32. For example, if the network 8
receives a request from the browser routine 64 for a particular
HTML document that may be obtainable from the network 8, the server
12 may analyze the obtained HTML document and determine whether or
not it includes one or more URLs from which may be obtained objects
that should be included in the HTML document. The server 12 may
determine from its mirror of the browser cache 32 whether or not
the object which is available at a given URL might already be
stored in the browser cache 32. If the object is not already stored
in the browser cache 32, the server 12 will request the object from
the URL and will send the object to the handheld electronic device
4, typically in conjunction with the sending of the HTML document
from the server 12 to the handheld electronic device 4. On the
other hand, if the object from the indicated URL is already
available in an unexpired condition in the browser cache 32, the
object is not at that time requested from the URL. In accordance
with the disclosed and claimed concept, the mirror of the browser
cache 32 is advantageously updated whenever the browser cache 32
changes.
[0022] Whenever a browser session is initiated, a data table 68,
such as is depicted generally in FIG. 2, is generated and is stored
in the memory 28. The data table 68 includes a number of first
objects 72 and a number of second objects 76 stored therein. Each
first object 72 comprises a file name 40, which is the file name 40
of a file 36 in the browser cache 32. Each first object 72 has
associated therewith a second object 76 that comprises the
location, i.e., the URL 48 in the present example, of the same file
36. In the depicted exemplary implementation, the file names 40 are
each stored in the first objects 72 as a hash of the file name 40
in order to reduce storage requirements and to facilitate
processing.
[0023] After the data table 68 has been created, a hash of each URL
48 in the second objects 76 is provided to the server 12 to create
on the server 12 the mirror of the browser cache 32. It may
additionally be desirable to provide, in conjunction with each hash
of a URL 48, the expiry date 52 of the object 44 that was obtained
from the same URL 48, as is stored in one of the files 36.
[0024] Whenever the contents of the browser cache 32 undergo a
change, the change is advantageously communicated to the server 12
so that the mirror on the server 12 of the browser cache 32 can be
updated in order to enable the mirror of the browser cache 32 to
accurately reflect the contents of the browser cache 32 on the
handheld electronic device 4. In response to a change in the
browser cache 32, the API 60 is configured to provide to the
browser routine 64 the name of the file 36 in the browser cache 32
that has undergone the change. The API 60 also provides a
notification of the type of change undergone by the file 36 of
which the file name 40 has just been provided. The various
notifications include a CREATE notification, an UPDATE
notification, a DELETE notification, and a RENAME notification
indicating that a particular file has been created, updated,
deleted, or renamed, respectively. In the case of a RENAME
notification, typically two file names 40 are provided, i.e., the
initial file name 40 of the file 36, as well as a new name for the
same file 36.
[0025] It is noted, however, that merely providing the file name 40
of the file 36 that has undergone a change does not itself provide
the URL 48 of the same file 36, and such URL 48 cannot be obtained
directly from the operating system 56 or the API 60. The browser
routine 64 is advantageously configured to obtain in other fashions
the particular URL 48 of the file 36 in the browser cache 32 that
has undergone the change.
[0026] FIG. 3 generally depicts an exemplary flowchart depicting
certain aspects of the way in which the server 12 is able to have a
substantially continuously updated mirror of the browser cache 32
that is stored on the handheld electronic device 4. As indicated
above, upon initiation of a browser session by the browser routine
64, the data table 68 is generated, as at 104. At least a portion
of the data table 68 is then supplied, as at 108, to the server 12.
As indicated above, typically what is supplied to the server 12 is
a hash of each URL 48 stored in the second objects 76, along with
the corresponding expiry date 52.
[0027] The browser routine 64 receives from the API 60 a
notification, as at 112, that a certain file 36 has undergone a
change. Specifically, the file name 40 of the file 36 that has
undergone the change, as well as a notification type are provided
to the browser routine 64. As indicated above, the four exemplary
types of notifications are CREATE, UPDATE, DELETE, and RENAME.
[0028] It is then determined, as at 116, whether the notification
was a CREATE notification. If not, it is then determined, as at
120, whether the notification was a DELETE notification or an
UPDATE notification. If not, the notification is ignored, as at
124. However, if it was determined at 120 that the notification was
either DELETE or UPDATE, the browser routine 64 obtains, as at 128,
from the data table 68 the URL 48 that is associated with the
received file name 40. More specifically, the data table 68 is
consulted to identify the first object 72 which has stored therein
a file name 40 that is the same as the received file name 40. The
second object 76 associated therewith is consulted to obtain the
URL 48 stored therein. The URL 48 and other appropriate data are
then supplied, as at 132, to the server 12. The data table 68 is
then updated, as at 136, to reflect the change that was notified at
112, assuming that the notification was not ignored at 124.
[0029] With more particular regard to the additional data that can
be supplied, as at 132, to the server, it is noted that a
notification which is a DELETE notification will generally result
in supplying to the server 12 a hash of the URL 48 of the deleted
file 36, along with a notification that the change was a DELETE.
The server 32 will previously have stored in its mirror of the
browser cache 32 a hash of the URL 48 in the file 36 that is being
deleted. Upon receiving the update transmission, as at 132, the
server will delete from its mirror of the browser cache 32 the hash
of the URL 48 of the deleted file 36.
[0030] However, if the notification received at 112 was an UPDATE
notification, updated data such as an updated expiry date 52
typically will be supplied, as at 132, to the server 12. Such
updated data can be obtained in any of a variety of ways. Such
updated data can even be obtained from the server 12.
[0031] For instance, the browser routine 64 may make a request of
the server 12 for a specific HTML document. After receiving the
request, the server will obtain, such as from the network 8, the
requested HTML document. The obtained HTML document may comprise
one or more URLs, and the server 12 may determine from its mirror
12 of the browser cache 32 that the object available at a
particular indicated URL is already stored on the handheld
electronic device 4 as an object 44 in the browser cache 32.
However, the server 12 may also determine that the expiry date 52
of the object 44 has been exceeded, i.e., the object 44 has
expired. In this regard, the browser cache 32 may be configured to
delete files 36 when the expiry date 52 of the object 44 stored
therein has been exceeded. On the other hand, however, the browser
cache 32 may be configured such that the file 36 having stored
therein an exceeded expiry date 52 is not necessarily deleted, but
the object 44 stored therein is updated if requested after
expiration of the expiry date 52.
[0032] The server 12 might make the determination that the expiry
date 52 of the object 44 has been exceeded by first creating a hash
of the URL contained within the obtained HTML document. The server
12 will then identifying in its mirror of the browser cache 32 the
matching URL hash, and determining whether the expiry date 52 that
is associated with the identified matching URL hash has been
exceeded.
[0033] If the server 12 determines that the expiry date 52 of an
object 44 stored in the browser cache 32 has been exceeded, the
server 12 may make a new request of the object from the URL. A
header of the request may include an instruction to the URL that it
provide the object stored at the URL only if the object has changed
since being stored in the browser cache 32. If it turns out that
the object is not changed, the URL may simply return to the server
12 an updated expiry date.
[0034] The updated expiry date will then be transmitted to the
handheld electronic device 4, and the operating system 56 will
store the received expiry date as an updated expiry date 52 in the
corresponding file 40. Such an update will cause the API 60 to
generate an UPDATE notification which will be received by the
browser routine 64, as at 112. As such, when at 132 the browser
routine 64 supplies to the server 12 the URL 48 and appropriate
additional data, part of the additional data will be the updated
expiry date 52 that has already been stored in the file 36 within
the browser cache 32.
[0035] If the URL returns to the server 12 a different object than
is stored in the browser cache 32, the same URL will likely
additionally provide an updated expiry date. The server then would
transmit to the handheld electronic device the updated object and
updated expiry date, and these would both be saved in the file 36,
with the API 60 generating an UPDATE notification at 112, and with
the updated expiry date 52 being supplied, as at 132 to the server
12.
[0036] If at 116 it is determined that the notification was a
CREATE notification, processing continues to 144 where the browser
routine 64 requests from the operating system 56 the name of a file
36 that comprises a URL 48 which was the subject of a recent
request by the browser routine 64. That is, during a browsing
session the browser routine 64 makes a number of browser requests
of the server 12. The fact that a particular URL request was made
by the browser routine 64 does not indicate whether or not a file
36 having the particular URL stored therein was recently added to
the browser cache 32 since it is possible that the object 44 which
would otherwise be available at the URL on the network was already
stored in the browser cache 32. However, the browser routine 64
maintains a list of recent URL requests. As such, at 144 the
browser routine 64 requests of the operating system 56 the name of
a file 36 having a particular URL 48 stored therein. The particular
URL 48 typically will be the URL that was the subject of the most
recent URL request by the browser routine 64.
[0037] In response to the request at 144, the operating system 56
may return a file name 40 or may return nothing. It is then
determined, as at 148, whether the returned file name 40, if any,
and the file name 40 that was generated as part of a notification
at 112 are the same. If they are not the same, or if no file name
was returned in response to the request at 144 regarding a
particular URL, processing returns to 144 where additional requests
are made for additional URLs that were the subject of recent URL
requests. In this regard, the URLs employed in the requests at 144
typically will be made in reverse chronological order, i.e., the
most recent URL will be the subject of the first request at 144,
and if the result at 148 is "no", a successive request at 144 will
be made with respect to the URL that was next most recently
requested by the browser routine 64, and so forth.
[0038] In response to one of the requests at 144, the operating
system 56 will return a file name 40 that matches the file name 40
that was generated as part of the notification at 112. In such a
circumstance, a hash of the URL that was the subject of the
successful request is supplied, as at 132, to the server 12. The
data table 68 is then updated, as at 136.
[0039] As a general matter, the API 60 is capable of generating
numerous notifications that may be in excess of what is necessarily
or desirably handled by the routines on the handheld electronic
device 4. For instance, the API 60 may generate numerous
notifications in response to a single event. By way of example, it
is noted that an updating operation on the handheld electronic
device 4 may generate five separate notifications as follows:
[0040] 1) the device may create a new file, thus resulting in a
CREATE notification;
[0041] 2) the device may update the new file by writing into the
new file the contents of an old file, thus generating an UPDATE
notification;
[0042] 3) the device may append any changes, i.e., edit, the new
file, thus resulting in an UPDATE notification;
[0043] 4) the device may delete the old file, thus resulting in a
DELETE notification; and
[0044] 5) the device may rename the new file to have the name of
the old file and to have the attributes of the old file, thus
resulting in a RENAME notification.
[0045] In essence, the only meaningful change to the browser cache
32 was the updating of the old file, but the way in which the
updating occurred resulted in the generation of five notifications,
only one of which is particularly meaningful, such as to the
browser routine 64. On the other hand, a routine other than the
browser routine 64 might find more than one of the five
notifications to be useful or relevant.
[0046] In accordance with the disclosed and claimed concept, the
notifications generated by the API 60 are advantageously subjected
to one or more predetermined criteria or algorithms to determine
whether or not one or more of the notifications can be ignored. It
is noted that the various predetermined criteria, i.e., algorithms,
likely will be specific to a given routine on the handheld
electronic device 4. That is, what may be an unnecessary or
irrelevant notification to one routine might be relevant or
desirably noted by another routine.
[0047] The browser routine 64 is provided herein as an exemplary
routine to which certain notifications generated by the API 60 may
desirably be ignored. It is reiterated that certain of the
algorithms may be usable in conjunction with other routines than
the browser routine 64, and that other algorithms may be unusable
with routines other than the browser routine 64. Also, other
routines may have other predetermined criteria or algorithms for
use in determining whether certain of the notifications can be
ignored by the routines.
[0048] One of the predetermined criteria, i.e., one algorithm, is
to determine whether or not a notification relates to a particular
type of file. For instance, a certain routine may find relevant
only those notifications that relate to a file having a suffix
".txt". As is mentioned above, the API 60 may generate a number of
notifications that each comprise the type of notification, i.e.,
CREATE, UPDATE, DELETE, or RENAME, as well as the file name 40 of a
file 36 that was the subject of the notification. If the particular
routine finds relevant only those particular notifications that
relate to a ".txt" file, any notification that relates to a file
that is of a type other than a ".txt" file will be ignored.
[0049] However, a RENAME notification from a file type that the
particular routine does not consider relevant into a file name that
the routine does consider to be relevant will be ignored and
instead treated as a CREATE notification of the file name that the
routine considers to be relevant. For instance, a RENAME
notification of a file 36 from filename.tmp to filename.txt will be
treated as a CREATE notification of filename.txt. Similarly, a
RENAME notification from a file type that the particular routine
considers to be relevant into a file name that the routine does not
consider to be relevant will be ignored and instead treated as a
DELETE notification of the file name that the routine considers to
be relevant.
[0050] It is noted that ignoring a notification can occur in two
fashions. In the first fashion, ignoring a notification can simply
mean paying no attention to the notification, with no subsequent
action. The other fashion of ignoring a notification can occur by
paying no attention to the notification that was received, and
rather treating the notification as a different notification. The
different notification can be of a different type and/or can be as
to a different file.
[0051] Notifications typically are received from the API 60 as a
sequence, i.e., a plurality of notifications are sequentially
received from the API 60. The exemplary browser routine 64 may
initiate analysis of the notifications, i.e., for the purpose of
potentially ignoring certain of the notifications, in response to
any of a variety of events. For instance, the browser routine 64
might employ a timer which is reset upon each receipt of a
notification. The timer may be set to a particular period of time,
i.e., a period of two seconds, or another appropriate time period.
If the timer expires without detecting another notification from
the API 60, the analysis of the series of notifications may be
initiated. On the other hand, notifications may be identified as
being in discrete "bunches" which are analyzed together. Other
triggering events can be envisioned.
[0052] It is noted, however, that an analysis of a relatively
greater number of notifications will have a more appropriate result
than an analysis of a relatively lesser number of notifications.
This is due, at least in part, to the nature of the analysis. As a
general matter, each notification is analyzed as being a "current"
notification and is analyzed in the context of a "following"
notification in the sequence. That is, notifications are analyzed
in pairs. In the examples set forth herein, the "following"
notification is a sequentially next notification immediately
following the "current" notification, but it is noted that the
"following" notification could, in appropriate circumstances, be
sequentially later than the immediately next notification after the
"current" notification.
[0053] An exemplary set of criteria, i.e., algorithms, are set
forth in the accompanying Table 1 below:
TABLE-US-00001 TABLE 1 "Following" Notification RENAME from CREATE
file UPDATE file DELETE file "filename2.txt" to "filename1.txt"
"filename1.txt" "filename1.txt" "filename1.txt" "Current" CREATE
file Ignore the CREATE Ignore the Keep both Keep both CREATE
Notification "filename1.txt" notification of UPDATE CREATE and and
RENAME "filename1.txt" notification DELETE notifications
notifications UPDATE file Ignore the CREATE Ignore the Keep both
Keep both UPDATE "filename1.txt" notification of UPDATE UPDATE and
and RENAME "filename1.txt" notification DELETE notifications
notifications DELETE file If the notification before Keep both
Ignore one Replace these 2 "filename1.txt" the DELETE was a DELETE
and DELETE notifications with: CREATE or UPDATE, UPDATE
notification DELETE filename2.txt then, ignore this notifications
and UPDATE DELETE and CREATE filename1.txt of "filename1.txt".
Otherwise, replace these 2 notifications with an UPDATE
notification for "filename1.txt". RENAME from Keep both RENAME Keep
both Keep both Ignore one RENAME "filename2.txt" and CREATE RENAME
and RENAME and notification to notifications UPDATE DELETE
"filename1.txt" notifications notifications
[0054] As can be seen from Table 1, if either a CREATE
notifications or an UPDATE notification (as a "current"
notification) is followed by either a CREATE notification or an
UPDATE notification (as a "following" notification) as to the same
file, the "following" notification is ignored. For other routines,
i.e., other embodiments, the algorithm might be to ignore either
the "current" notification or the "following" notification, and to
treat the non-ignored notification as an UPDATE notification.
[0055] As can further be seen from Table 1, if either a CREATE
notification or an UPDATE notification is followed by either a
DELETE notification or a RENAME notification that indicates a
deletion of the same file or a renaming of another file to the same
file, both notifications may be kept, i.e., not ignored. This may
be based, at least in part, upon the unlikelihood of detecting from
the API 60 such a pair of notifications. Table 1 thus suggests that
if such an unlikely pair of notifications is detected, the
notifications are not ignored. As an alternative, another routine
might choose to ignore both notifications in such a
circumstance.
[0056] If two sequentially consecutive notifications are precisely
the same, i.e., of the same nature and as to the same file, another
algorithm might be to ignore one of the two notifications. With
other routines, however, possibly neither notification is ignored
due to the unlikeliness of receiving such a pair of
notifications.
[0057] In the circumstance of a DELETE notification followed by a
CREATE notification as to the same file, it is determined whether
or not the notification that preceded the DELETE notification was
either a CREATE notification or an UPDATE notification. If so, the
current DELETE and the following CREATE notifications are ignored.
However, if the notification preceding the DELETE notification was
neither a CREATE nor an UPDATE notification, the current DELETE
notification and the following CREATE notification are ignored and
are treated as a single UPDATE notification as to the same file.
For other routines, the same result can be obtained when the
current DELETE notification is followed by an UPDATE notification
rather than the aforementioned CREATE notification.
[0058] As can further be seen from Table 1, if a DELETE
notification as to a particular file is followed by a RENAME
notification renaming another file to the name of the particular
file, such notifications are replaced with a DELETE notification as
to the another file and an UPDATE notification as to the particular
file. In effect, the two original notifications are ignored, and
are treated as two different notifications. Alternatively, the two
notifications could be treated as a DELETE notification as to the
another file and a CREATE notification as to the particular file.
The two different notifications can then be analyzed in the context
of the other notifications in the sequence of notifications being
analyzed in order to possibly ignore one or more of these
notifications or other notifications in the series.
[0059] As can further be seen from Table 1, a RENAME of one file to
the name of another file which is followed by a CREATE, an UPDATE,
or a DELETE notification as to the another file will result in
neither notification being ignored. In other embodiments, however,
one or more of such notifications could potentially be ignored,
depending upon the needs of the routine.
[0060] As an example, a sequence of notifications to be analyzed
may be as follows:
TABLE-US-00002 CREATE filename.tmp UPDATE filename.tmp UPDATE
filename.tmp UPDATE filename.tmp UPDATE filename.txt DELETE
filename.txt RENAME filename.tmp to filename.txt UPDATE
filename.txt.
[0061] As a first step we may ignore the notifications for files of
a type about which the browser routine 64 is not concerned. For
example, all notifications relating to a file name other than a
".txt" file will be ignored. However, the RENAME notification from
filename.tmp to filename.txt will be treated as a CREATE
notification of filename.txt. This leaves the following:
TABLE-US-00003 UPDATE filename.txt DELETE filename.txt CREATE
filename.txt UPDATE filename.txt.
[0062] When the first two notifications are considered as a
"current" and a "following" notification, Table 1 indicates that an
UPDATE notification followed by a DELETE notification as to the
same file results in both notifications being kept. If the
aforementioned DELETE notification is now considered a "current"
notification and is analyzed in the context of the subsequent
CREATE notification being a "following" notification, Table 1
indicates' that a DELETE notification that is preceded by an UPDATE
notification and followed by a CREATE notification as to the same
file name, will result in the DELETE and the following CREATE
notifications both being ignored.
[0063] In the circumstance of a "following" notification being
ignored, the next "current" notification to be analyzed will be the
most immediately preceding notification that has not yet been
ignored. Thus, the first UPDATE notification will again be
considered as a "current" notification, and will be considered to
be followed by the second UPDATE notification. Table 1 indicates
that an UPDATE notification followed by another UPDATE notification
as to the same file will result in the second UPDATE notification
being ignored.
[0064] In the context of the exemplary browser routine 64,
therefore, seven of the eight notifications in the exemplary
notification sequence above were ignored. As a result, the method
indicated for example by the flowchart in FIG. 3 would need to be
executed only once, i.e., for the sole remaining UPDATE
notification, rather than executing the same routine eight separate
times. This advantageously saves executing and power resources.
[0065] Such a method is depicted generally in the exemplary
flowchart of FIG. 4. For instance, the browser routine 64 listens,
as at 204, for notifications from the API 60. It is determined, as
at 208, whether or not a notification was received. If a
notification was received, the timer is reset, as at 212, and
processing returns to 204 where the browser routine 64 listens for
further notifications. If at 208 it is determined that no
notification was received in the preceding listening operation at
204, it is then determined, as at 216, whether or not the timer has
expired. If not, processing returns to 204 where further listening
occurs.
[0066] In this regard, it can be understood that the exemplary
steps 204, 208, 212, and 216 form a loop that is repeated at
certain intervals, perhaps as often as the processor can execute
the loop. Once the timer has expired without having received an
additional notification, processing continues to 220 whether it is
determined whether or not any of the notifications meet any of the
predetermined criteria, i.e., the criteria that are predetermined
for the routine performing the listening at 204 or for which the
notifications are being detected. If no notifications meet the
predetermined criteria, the notifications are acted upon, as at
224. Such notifications may be acted upon by being stored, by
initiating other processing, or in other fashions.
[0067] If, however, at 220 it is determined that some of the
notifications meet one or more of the predetermined criteria,
processing continues at 228 where certain of the notifications are
ignored and, as appropriate, may be treated as being different
notifications. Processing thereafter continues at 224 where the
remaining notifications are acted upon.
[0068] With further regard to the operations at 220, it is
understood that any of a variety of criteria, i.e., algorithms, can
be employed depending upon the needs of the particular routine in
question. As such, algorithms in addition to those set forth herein
can be employed without departing from the present concept.
[0069] While specific embodiments of the disclosed and claimed
concept have been described in detail, it will be appreciated by
those skilled in the art that various modifications and
alternatives to those details could be developed in light of the
overall teachings of the disclosure. Accordingly, the particular
arrangements disclosed are meant to be illustrative only and not
limiting as to the scope of the disclosed and claimed concept which
is to be given the full breadth of the claims appended and any and
all equivalents thereof.
* * * * *