[mashup-dev] The AtomFeedHosObject
Thilina Gunarathne
thilina at wso2.com
Sun Aug 5 17:58:32 PDT 2007
>I need to take a look at the APPClient host object more to ensure
>whether it will remain the same. I have a feeling that it's closer to
>the Abdera implementation than the Atom spec.
I don't think so :)... It just implements get,post, delete, put from the
Atom Publishing Protocol.
>My suggestion is that, we keep our APPClient host object API as generic
>as possible. That way we can change the background java implementation
>we use at will.
+1.. Please come up with the suggestions.
>Yet another reason to re-think
>our host object API implementation and make it closer to the original
>Atom spec rather than any implementation out there.
Yes. It should be.. Our host objects should provide a java scriptish
minimalistic API capturing the possible use cases rather than becoming
wrappers to the java API's.. AFAIK almost all the implemented host object
implementations already follow this, including the APP, atom, etc.. If not
please point out the exceptions and we need to correct them ASAP.
Thanks,
Thilina
Tyrell
>
> Things to be aware of,
> 1. I've seeing mails stating that ROME is suffering from lack of
> developers[1]. Please find out about the continuity of the project before
> committing in to it.
> 2. Performance figures mentioned in here [2].
>
> Thanks,
> Thilina
>
>
>
[1]http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/200705.mbox
> /%3C46464061.50806 at gmail.com%3E
> [2] http://www.infoq.com/news/Abdera-Merger-ROME
>
> -----Original Message-----
> From: mashup-dev-bounces at wso2.org [mailto:mashup-dev-bounces at wso2.org] On
> Behalf Of Tyrell Perera
> Sent: Sunday, August 05, 2007 9:53 AM
> To: mashup-dev at wso2.org
> Subject: Re: [mashup-dev] The AtomFeedHosObject
>
>
>
> Sanjiva Weerawarana wrote:
>> Does ROME give us a consistent API for supporting both Atom and RSS? If
>
> It has an implementation called a syndFeed (short for syndication feed),
> which is supposed to handle both Atom and RSS.
>
> <quote>
>
> ROME includes parsers to process syndication feeds into SyndFeed
> instances. The SyndFeedInput class handles the parsers using the correct
> one based on the syndication feed being processed.
>
> The developer does not need to worry about selecting the right parser
> for a syndication feed, the SyndFeedInput will take care of it by
> peeking at the syndication feed structure. All it takes to read a
> syndication feed using ROME are the following 2 lines of code:
>
> SyndFeedInput input = new SyndFeedInput();
> SyndFeed feed = input.build(new XmlReader(feedUrl));
>
> </quote>
>
>
> Tyrell
>
>
>> so +1 for moving to ROME. (Is the license BSD-compatible?)
>>
>> Sanjiva.
>>
>> Tyrell Perera wrote:
>>> I came across 'Project ROME' by Sun https://rome.dev.java.net/
>>>
>>> This looks like a much cleaner implementation as well. It supports
>>> atom, rss and an abstract format, which is capable of modeling both.
>>>
>>> It looks complete as an implementation. For example the 'remove'
>>> functionality for entries :) It is also well documented, with
>>> tutorials on how to read, aggregate and create feeds.
>>>
>>> Expecting your comments on whether to replace Abdera with this...
>>>
>>> Tyrell
>>>
>>>
>>> Thilina Gunarathne wrote:
>>>>> I also found a Feed interface in Abdera
>>>>> (http://incubator.apache.org/abdera/docs/api/index.html), which
>>>>> provides
>>>>> most of the functionality we require. I'm using it as a starting point
>>>>> and already committed some code.
>>>> To my surprise, it does not have a method to remove an entry... Not
>>>> sure whether it is by design or
>>>> by mistake..
>>>>> Hopefully we will not need the saveFeed() method. That is if it's been
>>>>> handled internally by Abdera.
>>>>> From a user perspective I would like to have the control over
>>>>> writing the things to the file..
>>>> AFAIKS Abdera Feed has a writeTo(outStream) method inherited from
>>>> org.apache.abdera.model.Base[1]
>>>> interface, which we will have to use for saving to the files..
>>>>
>>>> thanks,
>>>> Thilina
>>>>
>>>> [1]
>>>>
>
http://incubator.apache.org/abdera/docs/api/org/apache/abdera/model/Base.htm
> l
>>>>> Tyrell
>>>>>
>>>>> Thilina Gunarathne wrote:
>>>>>>> What're the methods on AtomEntry? Does it include "discard"?
>>>>>> ahh..yes... We can have something like removeEntry(string
>>>>>> id|AtomEntry entry) in the AtomFeed host
>>>>>> object.
>>>>>>
>>>>>>> Is updateEntry missing a parameter? How is it supposed to work?
>>>>>> I noticed this only now. I'm wondering whether we need this at all..
I
>>>>>> can visualize the updating of
>>>>>> an entry as follows.
>>>>>> 1. Getting the reference to the necessary entry from the feed
>>>>>> 2. Do any necessary updates to the properties of that entry,
>>>>>> These updates will be represented automatically in the feed
as
>>>>>> entry is part of the feed.
>>>>>>
>>>>>> Eg:
>>>>>> feed = new AtomFeed(atom.xml);
>>>>>> entry = feed.getEntry(5);
>>>>>> entry.content="<test1/>";
>>>>>>
>>>>>> I don't see a need to call updateEntry in the above scenerio.
>>>>>>
>>>>>>> -1 to "flush()" as a syonymn for "persist". The only things I
>>>>>>> flush are
>>>>>>> things I never want to see again. How about simply "save()"?
>>>>>> +1 for save() or saveFeed() in case 'save' is a reserved word ;-)..
>>>>>>
>>>>>> I think we should start capturing this API in the WIKI and continue
>>>>>> the discussion in this list..
>>>>>>
>>>>>> thanks,
>>>>>> Thilina
>>>>>>
>>>>>>> Jonathan Marsh - http://www.wso2.com -
>>>>>>> http://auburnmarshes.spaces.live.com
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: mashup-dev-bounces at wso2.org
>>>>>>>> [mailto:mashup-dev-bounces at wso2.org]
>>>>>>>> On Behalf Of Thilina Gunarathne
>>>>>>>> Sent: Tuesday, July 31, 2007 4:50 AM
>>>>>>>> To: tyrell at wso2.com; mashup-dev at wso2.org
>>>>>>>> Subject: Re: [mashup-dev] The AtomFeedHosObject
>>>>>>>>
>>>>>>>> Please find the comments inline..
>>>>>>>>
>>>>>>>> Tyrell Perera wrote:
>>>>>>>>> Here's the basic structure after the initial discussions.
>>>>>>>>>
>>>>>>>>> -
> AtomFeedHosObject(absolute_url/relative_url/file_path/FileHostObject,
>>>>>>>> Assume this is Hos*t*Object ;-)
>>>>>>>>> isAutoPersist)
>>>>>>>>> The constructor, which will be overloaded to handle
>>>>>>>> different
>>>>>>>>> locations. It also takes in a boolean value indicating persistence
>>>>>>>>> handling. If the value of isAutoPersist is 'true' the user doesn't
>>>>>>>> have
>>>>>>>>> to call persistFeed() method after every change to the Feed and
its
>>>>>>>>> entries.
>>>>>>>> Why do we need the isAutoPersist.. IMHO we can live with just the
>>>>>>>> persistFeed(). Then the user can
>>>>>>>> do whatever the edits he needs to the entries and then he can
>>>>>>>> persist
>>>>>>>> it once. If he needs he can to
>>>>>>>> persist it after each and every edit, then he can get it done by
>>>>>>>> calling persistFeed() after each
>>>>>>>> and every edit. In order to do this we'll need to add a hook to
each
>>>>>>>> and every setter method in
>>>>>>>> AtomEntry and AtomFeed, which can become a maintainance pain in
the
>>>>>>>> long run.
>>>>>>>>
>>>>>>>> Persisting the feed is a very costly operation. In there we'll be
>>>>>>>> writing the whole file to the file
>>>>>>>> system each and every time we persist it. Also in our server side
>>>>>>>> service scripting, most common use
>>>>>>>> case is executing a chunk of code after a service invocation as
>>>>>>>> follows.
>>>>>>>>
>>>>>>>> Eg:
>>>>>>>> function myOperation(){
>>>>>>>> feed = new AtomFeed(atom.xml);
>>>>>>>> entry1 = feed.getEntry(5);
>>>>>>>> entry1.content="<test1/>";
>>>>>>>> entry2 = new AtomEntry(........................);
>>>>>>>> feed.appendEntry(entry2);
>>>>>>>> feed.persisteFeed();
>>>>>>>> }
>>>>>>>>
>>>>>>>> In the above use case I do not see any advantage of auto persist.
>>>>>>>>> - appendEntry(AtomEntryHostObject)
>>>>>>>>> This adds a new entry to the feed
>>>>>>>>>
>>>>>>>>> - updateEntry(AtomEntryHostObject)
>>>>>>>>> Seeks and updates an existing entry
>>>>>>>>>
>>>>>>>>> - getEntry(id)
>>>>>>>>> Returns an AtomEntryHostObject from the feed using a given
>>>>>>>>> entry
>>>>>>>> ID
>>>>>>>>> - getEntries()
>>>>>>>>> Returns an Array of AtomEntryHostObjects
>>>>>>>>>
>>>>>>>>> - persistFeed()
>>>>>>>> How about "flush()"..
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Thilina
>>>>>>>>
>>>>>>>>> Writes the feed to persistent storage. The user has the
>>>>>>>>> option of
>>>>>>>>> enabling auto persist. If not this method needs to be called in
>>>>>>>>> order
>>>>>>>> to
>>>>>>>>> persist modifications done to the feed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Expecting your comments and suggestions ...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tyrell
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Mashup-dev mailing list
>>>>>>>> Mashup-dev at wso2.org
>>>>>>>> http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
>>>>>>> _______________________________________________
>>>>>>> Mashup-dev mailing list
>>>>>>> Mashup-dev at wso2.org
>>>>>>> http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
>>>>>>>
>>>>
>
--
Tyrell Perera
Senior Software Engineer; WSO2, Inc.; http://www.wso2.com/
email: tyrell at wso2.com; cell: +94 77 302 2505
"Oxygenating the Web Service Platform."
_______________________________________________
Mashup-dev mailing list
Mashup-dev at wso2.org
http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
--
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.6/900 - Release Date: 7/14/2007
3:36 PM
More information about the Mashup-dev
mailing list