Hi,
Am 14.03.12 17:09, schrieb Kay Schenk:
On Wed, Mar 14, 2012 at 1:15 AM, Oliver-Rainer Wittmann<
orwittm...@googlemail.com> wrote:
Hi,
On 13.03.2012 17:53, Kay Schenk wrote:
On Tue, Mar 13, 2012 at 5:54 AM, Roberto Galoppini<rgalopp...@geek.net>**
wrote:
[snipping a lot ...]
We have already investigated how it works, and we do actually serve
updates requests answering that there are no updates. This is just as
it was configured before.
Any information about how the update protocol works would be helpful
for the future, though.
Roberto
OK, I have an odd question. Is this the same "update protocol" that is
used
to update the actual base package -- i.e. OOo -- the same "update"
capability that is currently missing from, say, the existing Linux 32-bit
build?
Roberto-- where can we get more info on what is actually being "served" in
response to update request? That is, the URL for it.
*IF* the same "update protocol" is used for everything, base package and
extensions, here is what I (we) know. Apparently, there was some
proprietary tool in place from what I gather in which entries were
(manually?) entered for "products". That tool created atom feeds at a
specified URL which the "products/extensions" would then reference for
updates.
In building, both Regina and Ariel were able to successfully test an
"update" by creating an atom feed with a single entry for their respective
platforms (windows, linux-64 with debian packaging), and I think actually
perform the update.
There is information on the "format" of the feed on the wiki:
http://wiki.services.**openoffice.org/wiki/Update_**Notification_Protocol<http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol>
but NOTHING about how the feed gets constructed.
I have been wanting to experiment with adding more than one entry to the
existing sample feed I ported (usign Ariel's test) to:
http://www.openoffice.org/**ProductUpdateService/check.**Update<http://www.openoffice.org/ProductUpdateService/check.Update>
If someone knows enough to add more "entries" to this feed complying to
"atom" rules, that would be great. I don't know anything about how
"matches" occur in this context.
I am testing the function Menu Help - Check for Updates... regarding, if
it is working after we had back an HTTP/WebDAV client library.
It mainly works using [1]. But, I have recognized that the HTTP header
fields specified at [2] are not transfered - mea culpa.
--> I will submit a corresponding issue for which I will request the
release blocker flag.
It looks like that the former update service used the values of the HTTP
header fields "User-Agent" and "Accept-Language" in order to provide a
proper reply.
I think "User-Agent" was used to determine, if for the requested installed
version an update exists or not. "Accept-Language" seems to be used provide
a corresponding localized reply.
These are only guesses. Feel free to correct or even support me.
After fixing the above mentioned issue I will try to analyse the code
processing the response in order to continue Regina's and Ariel's work here.
I expect that it results in proper information which enabled us to provide
a 'static' reply which will signal to all OOo 3.3 versions that AOO 3.4 is
available.
[1]
http://www.openoffice.org/**ProductUpdateService/check.**Update<http://www.openoffice.org/ProductUpdateService/check.Update>
[2] http://wiki.services.**openoffice.org/wiki/Update_**
Notification_Protocol<http://wiki.services.openoffice.org/wiki/Update_Notification_Protocol>
Best regards, Oliver.
Oliver--Thanks.
I too am continuing my investigation, though, since I am NOT a C++ coder,
well...not so simple.
I have already started to document my findings at [2].
I will continue tomorrow morning (German time).
For short: I think I have found everything which is needed to bring a
"update service" back. We should discuss when I have provided all my
findings.
Best regards (and stay tuned),
Oliver.
