Re: Re: [platform-update-dev] Scenarios for update manager

["Alex Blewitt" <alex.blewitt@xxxxxxxxx>]

On 20/09/06, Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx> wrote:
> translatable metadata
> extensible metadata

Actually, you make a good point here ... if it is an XML file, we
shouldn't use anything as constrainable as a DTD or use a fixed
DTD-to-object mapping. Instead, we should have known
elements/attributes, and ignore anything that is not known, much like
the Manifest.MF allows arbitary data to be handled. That way, if newer
functionality gets added over time, it doesn't break existing clients.
(And my preference for parsing XML files such as this is to use XPath
expressions to select data from a document, because then it's
relatively easy to migrate at a later stage ... )

By 'translatable metadata', I assume that you mean
internationalisation, or localisation, or whatever NLS is being called
these days (as oppsed to, say, Manifest-to-XML translation). For what
it's worth, Atom supports different languages through the xml:lang
attribute and the link hreflang attribute :-)

> transparent support for mirrors

Yes, this will be a must. One other Atom-related fact; an atom entry
can define relative URIs and the Atom feed itself can define the base
URI from which all relative URIs can be resolved. This could be used
e.g. to define a standard repository structure for bundles on the
server, and then resolving to different mirrors is a case of changing
the base URI to something else. (A suitable way of storing bundles on
the server's repository is probably a good idea; ratherr than having a
one-dimensional list of bundles, maybe splitting them up into sub
directories e.g. org/eclipse/jface would contain all of the
org.eclipse.jface.* bundles)

> shared pool of plugins

I'm not sure what this means; I interpret it to mean being able to
utilise several sets of plugins stored in directories elsewhere on a
local system? Or did you mean a remote pool of plugins?

Alex.