Re: [wgo] GNOME Products



Simon, thanks for your reply (but please keep always gnome-web-list
CCed).

On Sat, 2006-11-25 at 23:11 +0100, Simon Rozet wrote:
> Quim Gil wrote :
> > http://live.gnome.org/GnomeWeb/GnomeProducts updated.
> >
> > Simon, we need to decide asap if we go for a Plone solution i.e.
> > http://plone.org/products/plonesoftwarecenter or something living
> > outside from Plone as you started doing back in August.
> 
> At first, thanks for your help on the planning of
> http://live.gnome.org/GnomeWeb/GnomeProducts
> 
> IMHO, the advantages of using an external plone solution is :

You mean a solution external to Plone.

> If DOAPs live in a shared space (like gnome's CVS) then WGO and each
> project's website can use the same data. No duplication.

Question to the Plone developers: can those DOAP files live elsewhere
and then be imported automatically to the wgo Plone? 

Would it be a possibility to consider to have the DOAP files inside
Plone but in a way that these data could be shared without duplication
by other websites?

The main requirement here is having just one source of data so editors
of wgo and the web projects can work together in a single place.


> > The complex part here seems to be a) the DOAP data shared with the
> > projects subsites and b) how translations will be handled.
> 
> a) For WGO, a cron could generate the static pages through a script.
> For the projects subsites, we could setup a REST API or something simpler.
> 
> b) It's possible to store translations in only one DOAP (see http://www-128.ibm.com/developerworks/xml/library/x-osproj3/doap-3-intl.jpg)
> I have no idea on the edit frontend side.

Well, this is a core reason why I think it would be good to try first a
solution integrated in Plone.

> > It's also time to define the available description fields of a
> > product, so we get all the same idea about these pages.
> 
> There's already a draft of this list on
> http://live.gnome.org/GnomeWeb/GnomeProducts
> We need to complete it. (there's also some questions about certain
> fields which need answers)

I have just posted there my opinion about the field "Category".
Applications could have the same category they have in the Applications
Menu. Probably apps under Preferences or Administration can keep that
too. We need to think the categories for the non-GUI components.
 
-- 
Quim Gil /// http://desdeamericaconamor.org

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]