Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [spaces-dev] An opportunity for Spaces

Ok, I updated the implementation of the interfaces to reflect this.
It made the construct more open ended - instead of the space and space
provider having "test/production" and "flat/nested" explicitly in the API,
requests now use a PublishingArea instance. Also modified how provider and
space report capabilities. Added an exception (UnsupportedPublishingArea).

Checked in rev 7493 in spaces.core

regards
- henrik

-----Original Message-----
From: Thomas Hallgren [mailto:thomas@xxxxxxx] 
Sent: torsdag 10 januari 2008 12:50
To: henrik.lindberg@xxxxxxxxxxxxxx; Developer discussions for the Spaces
project
Subject: Re: [spaces-dev] An opportunity for Spaces

Henrik Lindberg wrote:
> Thomas, are you suggesting that there should be two different ways to
> publish? One "structured" and one "flat"?
>
>   
I think we should consider it, yes.

> When we discussed this earlier we came up with the design to have a flag
for
> the publishing space that denotes if it supports "nestedFolders" (i.e.
> structure), and that publishing then should zip non single file
publishing.
>
> I think it would be much cleaner if a space could provide both a
structured
> and a flat area (supplying one of them is mandatory). I suppose we want
the
> new "flat" area to also be available in TEST and PRODUCTION flavor.
>
>   
I agree. This is a clean and simple way of doing it.

- thomas


> - henrik
>
> -----Original Message-----
> From: spaces-dev-bounces@xxxxxxxxxxx
[mailto:spaces-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Thomas Hallgren
> Sent: torsdag 10 januari 2008 12:37
> To: Developer discussions for the Spaces project
> Subject: Re: [spaces-dev] An opportunity for Spaces
>
> Indeed. This also highlights another aspect of publishing. A "downloads" 
> page is typically designed for zipped archives and such and hence, it's 
> flat as a pancake. In case of update sites, such a page is suitable for 
> publishing archived sites. The actual update site however, requires a 
> folder structure. In this particular case, this guy could probably 
> "publish" by using a folder in SVN that he tags. The SVN is, after all, 
> accessible using normal URL's (if it is public, that is).
>
> Question is, should we support two types of publishing in spaces? One 
> traditional "downloads" and one for structured storage? We can do both 
> using EFS of course, but the Space Provider might want to see them as 
> different things and the user might want to use both. What do you think?
>
> - thomas
>
> Bjorn Freeman-Benson wrote:
>   
>> http://www.norio.be/blog/2008/01/eclipse-update-site-google-code
>> -- 
>> [end of message]
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> spaces-dev mailing list
>> spaces-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/spaces-dev
>>   
>>     
>
> _______________________________________________
> spaces-dev mailing list
> spaces-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/spaces-dev
>
> _______________________________________________
> spaces-dev mailing list
> spaces-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/spaces-dev
>   




Back to the top