Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <48165424.1090204@mulesource.com>
Date: Mon, 28 Apr 2008 15:48:04 -0700
From: Dan Diephouse <dan.diephouse@mulesource.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: abdera-dev@incubator.apache.org
Subject: Re: dynamic collections
References: <20080428201336.740E.UCHIDA.HITOSHI@canon.co.jp>
	 <842030.18018.qm@web39206.mail.mud.yahoo.com>
	 <ce54216b0804281328y559098oc90511ece96e171d@mail.gmail.com>
	 <481634A7.4060305@gmail.com>
 <ce54216b0804281348p7e577185r4f08495adc12a1e2@mail.gmail.com>
 <4816489D.1090005@mulesource.com> <48164C3C.2030606@gmail.com>
In-Reply-To: <48164C3C.2030606@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I think I'm suggesting that it makes sense to do this by default and 
have a sensible default implementation in AbstractCollectionAdapter.

James M Snell wrote:
> There's no reason that the getServiceDocument method couldn't be 
> overridden so that it defers to a Collection Adapter.
>
> - James
>
> Dan Diephouse wrote:
>> What about
>> 1. Let the CollectionAdapter itself write to the services document 
>> whatever it wants.
>> 2. Add a switch to AbstractProvider which turns the service writing 
>> on/off
>> Would that solve your problem?
>>
>> Dan
>>
>> David Primmer wrote:
>>> But what about the issue of practicality of service docs for huge sets
>>> of dynamic collections?
>>>
>>> davep
>>>
>>> On Mon, Apr 28, 2008 at 1:33 PM, James M Snell <jasnell@gmail.com> 
>>> wrote:
>>>  
>>>> In the Lotus Connections blogs implementation, I subclassed the 
>>>> Provider and
>>>> re-implemented the code that provided the service document.  I have a
>>>> EntityProvider implementation that writes out the service document.
>>>>
>>>>  - James
>>>>
>>>>
>>>>
>>>>  David Primmer wrote:
>>>>
>>>>   
>>>>> I also had this same issue when the collections are dynamic and would
>>>>> generate a practically unusable service doc.
>>>>>
>>>>> /blabla/:collection/:entry
>>>>>
>>>>> There's now way that I know of to create a service doc for this feed
>>>>> if :collection is one of a large number records in a database. Why
>>>>> would anyone use the service doc it if it was more than just a
>>>>> handful? Service docs need to contain real working links, not uri
>>>>> templates.
>>>>>
>>>>> Abdera's method of creating service docs is to call getHref for each
>>>>> adapter that is added to the workspace. However, when an adapter
>>>>> handles getHref, it is generating one url, not generating all the
>>>>> entries in a feed. It can only return one url and that's going to be
>>>>> some form of template. Does it make sense to offer another
>>>>> implementation of AbstractProvider.getServiceDocument?
>>>>>
>>>>> davep
>>>>>
>>>>> On Mon, Apr 28, 2008 at 11:28 AM, M Harris <mdangel78@yahoo.com> 
>>>>> wrote:
>>>>>
>>>>>     
>>>>>> How can one create dynamic collections with Abdera and create the
>>>>>>         
>>>> service document?  Perhaps, a hierarchy. Instead of having a single 
>>>> static
>>>> collection defined, the user can create their own collections.  How 
>>>> would
>>>> one create a collection?  Should they post a collection element or 
>>>> atom
>>>> entry?
>>>>   
>>>>>>
>>>>>>
>>>>>>  ---------------------------------
>>>>>>  Be a better friend, newshound, and know-it-all with Yahoo! 
>>>>>> Mobile.  Try
>>>>>>         
>>>> it now.
>>>>   
>>>>>       
>>
>>


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com