You are viewing a plain text version of this content. The canonical link for it is here.
Posted to photark-dev@incubator.apache.org by Luciano Resende <lu...@gmail.com> on 2010/05/16 18:22:39 UTC
PhotArk Gallery API
I'd like to start working on defining a more robust API to access
photoArk galleries, I'm planning to start by creating a new module
(most likely a copy of current photark module) to avoid disrupting the
current web application. I'd start by applying REST with JSON as the
default wire format, and once we are ok with the new API, we could
start migrating the existent app to use this new API.
Thoughts ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: PhotArk Gallery API
Posted by Adriano Crestani <ad...@gmail.com>.
Hi Luciano,
- How to support this in a file system based gallery ?
We could unify the gallery impls and support only JCR as the main
impl. Filesystem would only be a AlbumService which is responsible for
loading the images from that specific source (filesystem) and
subscribing them in the JCRGallery. This way we could enable a gallery
that supports images from many different sources, not only filesystem.
I wonder how we can keep the original source in sync with the PhotArk
gallery, we could provide an API so the user would tell PhotArk
when/what to sync.
By the way, how about using Lucene instead of JackRabbit to store the
images and their info/tag? JackRabbit uses Lucene after all. Is there
any extra JackRabbit functionality that Lucene does not support? This
way we could integrate the image/album/tag repository with the search
index.
- How album subscriptions work on this scenario ? Is it just going to
be "lost" under the "all images" photo stream ? Do we force it to have
an associated tag, which really then becomes the concept of albums
again?
Subscription would only tell the gallery where the image is, then
later the user can add it to one or more albums, or set a tag to it
and etc. The image visibility would be up to the UI impl, PhotArk will
be mainly responsible for providing different ways to aggregate and
expose images, whether as albums, tags or search results.
- We have to come up with all sorts of unique id generation to
identify photos, as without the boundaries of albums, you can have
file name collisions when uploading two photos, with same file
DSC0001.jpg when they actually two different photos.
You are right, we would need an unique id instead of just the image
name, any idea?
Having said that, if others think this has more flexibility and would
be a better approach... and if someone is willing to help on the UI
side, I'm willing to start moving to that direction on the REST
branch.
I can help, mainly on the backend, I'm usually not the UI guy :)
Best Regards,
Adriano Crestani
On Thu, Jun 10, 2010 at 11:00 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Thu, Jun 10, 2010 at 12:46 AM, Adriano Crestani
> <ad...@apache.org> wrote:
>> Hi Luciano,
>>
>> The rest proposal looks good, some comments/questions below.
>>
>> Should we still keep the current model where images belong to a single
>> album? Phillipe's scenario, where he describes aggregated albums
>> referencing pictures that do not belong to them, would not work as
>> expected if we keep this approach, because a deleted album might
>> affect the contents of another album. I would also vote for a model
>> where pictures belong only to the gallery and albums only referencing
>> them. If we follow such model, the following rest APIs would need
>> changes:
>>
>
> So, I have entertained this approach as well, (and this is the
> approach taken by Flickr).
> My view is that this brings some complications:
> - How to support this in a file system based gallery ?
> - How album subscriptions work on this scenario ? Is it just going to
> be "lost" under the "all images" photo stream ? Do we force it to have
> an associated tag, which really then becomes the concept of albums
> again?
> - We have to come up with all sorts of unique id generation to
> identify photos, as without the boundaries of albums, you can have
> file name collisions when uploading two photos, with same file
> DSC0001.jpg when they actually two different photos.
> - I'm also not sure how big the impact on the user experience and in
> the UI itself.
>
> I'm also not sure if we can't really still provide all tag support on
> top of current album based gallery.
>
> Having said that, if others think this has more flexibility and would
> be a better approach... and if someone is willing to help on the UI
> side, I'm willing to start moving to that direction on the REST
> branch.
>
>> Image Operations
>>
>> – Retrieve a specific image from gallery
>>
>> GET http://localhost:8080/photark/gallery/dsc123.jpg
>>
>> – Add new image to gallery
>>
>> POST http://localhost:8080/photark/gallery/dsc123.jpg
>>
>> – Update new image to gallery
>>
>> PUT http://localhost:8080/photark/gallery/dsc123.jpg
>>
>> – Delete an image from gallery (this should consequently remove the
>> image reference from all albums)
>>
>> DELETE http://localhost:8080/photark/gallery/dsc123.jpg
>>
>> – Retrieve a list of image references for an album
>>
>> GET http://localhost:8080/photark/gallery/<album>/images
>>
>> – Add new image reference to album
>>
>> POST http://localhost:8080/photark/gallery/<album>/dsc123.jpg
>>
>> – Add an image reference from album
>>
>> DELETE http://localhost:8080/photark/gallery/<album>/dsc123.jpg
>>
>> Note: with this APIs the user won't be able to be aware of pictures if
>> they are not in an album, but if we want to, we can also add
>>
>> – Retrieve images from gallery
>>
>> GET http://localhost:8080/photark/gallery/images
>>
>>
>
> If images are uploaded directly to "gallery", this proposal won't work
> and we need to handle collisions with something like :
>
> GET http://localhost:8080/photark/gallery/124324223
>
> where 124324223 is a unique (and possible short) identifier for dsc123.jpg
>
>> Should we use http://localhost:8080/photark/gallery or
>> http://localhost:8080/photark/gallery/albums/
>>
>> +1 for http://localhost:8080/photark/gallery/albums/
>>
>> Do we ever need to retrieve a list of albums with full data ?
>>
>> Do you see any reason to not to?
>>
>
> If we still have albums, I believe that the most common scenario is
> that you retrieve a list of albums, and then show the contents of a
> given album. Not sure if you want to have the ability to return the
> content of all albums, which might be big. Having said that, it should
> be pretty easy to provide another endpoint to output the full content
> of the album, but it probably should not be the default behavior.
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: PhotArk Gallery API
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Jun 10, 2010 at 12:46 AM, Adriano Crestani
<ad...@apache.org> wrote:
> Hi Luciano,
>
> The rest proposal looks good, some comments/questions below.
>
> Should we still keep the current model where images belong to a single
> album? Phillipe's scenario, where he describes aggregated albums
> referencing pictures that do not belong to them, would not work as
> expected if we keep this approach, because a deleted album might
> affect the contents of another album. I would also vote for a model
> where pictures belong only to the gallery and albums only referencing
> them. If we follow such model, the following rest APIs would need
> changes:
>
So, I have entertained this approach as well, (and this is the
approach taken by Flickr).
My view is that this brings some complications:
- How to support this in a file system based gallery ?
- How album subscriptions work on this scenario ? Is it just going to
be "lost" under the "all images" photo stream ? Do we force it to have
an associated tag, which really then becomes the concept of albums
again?
- We have to come up with all sorts of unique id generation to
identify photos, as without the boundaries of albums, you can have
file name collisions when uploading two photos, with same file
DSC0001.jpg when they actually two different photos.
- I'm also not sure how big the impact on the user experience and in
the UI itself.
I'm also not sure if we can't really still provide all tag support on
top of current album based gallery.
Having said that, if others think this has more flexibility and would
be a better approach... and if someone is willing to help on the UI
side, I'm willing to start moving to that direction on the REST
branch.
> Image Operations
>
> – Retrieve a specific image from gallery
>
> GET http://localhost:8080/photark/gallery/dsc123.jpg
>
> – Add new image to gallery
>
> POST http://localhost:8080/photark/gallery/dsc123.jpg
>
> – Update new image to gallery
>
> PUT http://localhost:8080/photark/gallery/dsc123.jpg
>
> – Delete an image from gallery (this should consequently remove the
> image reference from all albums)
>
> DELETE http://localhost:8080/photark/gallery/dsc123.jpg
>
> – Retrieve a list of image references for an album
>
> GET http://localhost:8080/photark/gallery/<album>/images
>
> – Add new image reference to album
>
> POST http://localhost:8080/photark/gallery/<album>/dsc123.jpg
>
> – Add an image reference from album
>
> DELETE http://localhost:8080/photark/gallery/<album>/dsc123.jpg
>
> Note: with this APIs the user won't be able to be aware of pictures if
> they are not in an album, but if we want to, we can also add
>
> – Retrieve images from gallery
>
> GET http://localhost:8080/photark/gallery/images
>
>
If images are uploaded directly to "gallery", this proposal won't work
and we need to handle collisions with something like :
GET http://localhost:8080/photark/gallery/124324223
where 124324223 is a unique (and possible short) identifier for dsc123.jpg
> Should we use http://localhost:8080/photark/gallery or
> http://localhost:8080/photark/gallery/albums/
>
> +1 for http://localhost:8080/photark/gallery/albums/
>
> Do we ever need to retrieve a list of albums with full data ?
>
> Do you see any reason to not to?
>
If we still have albums, I believe that the most common scenario is
that you retrieve a list of albums, and then show the contents of a
given album. Not sure if you want to have the ability to return the
content of all albums, which might be big. Having said that, it should
be pretty easy to provide another endpoint to output the full content
of the album, but it probably should not be the default behavior.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: PhotArk Gallery API
Posted by Adriano Crestani <ad...@apache.org>.
Hi Luciano,
The rest proposal looks good, some comments/questions below.
Should we still keep the current model where images belong to a single
album? Phillipe's scenario, where he describes aggregated albums
referencing pictures that do not belong to them, would not work as
expected if we keep this approach, because a deleted album might
affect the contents of another album. I would also vote for a model
where pictures belong only to the gallery and albums only referencing
them. If we follow such model, the following rest APIs would need
changes:
Image Operations
– Retrieve a specific image from gallery
GET http://localhost:8080/photark/gallery/dsc123.jpg
– Add new image to gallery
POST http://localhost:8080/photark/gallery/dsc123.jpg
– Update new image to gallery
PUT http://localhost:8080/photark/gallery/dsc123.jpg
– Delete an image from gallery (this should consequently remove the
image reference from all albums)
DELETE http://localhost:8080/photark/gallery/dsc123.jpg
– Retrieve a list of image references for an album
GET http://localhost:8080/photark/gallery/<album>/images
– Add new image reference to album
POST http://localhost:8080/photark/gallery/<album>/dsc123.jpg
– Add an image reference from album
DELETE http://localhost:8080/photark/gallery/<album>/dsc123.jpg
Note: with this APIs the user won't be able to be aware of pictures if
they are not in an album, but if we want to, we can also add
– Retrieve images from gallery
GET http://localhost:8080/photark/gallery/images
Should we use http://localhost:8080/photark/gallery or
http://localhost:8080/photark/gallery/albums/
+1 for http://localhost:8080/photark/gallery/albums/
Do we ever need to retrieve a list of albums with full data ?
Do you see any reason to not to?
Best Regards,
Adriano Crestani Campos
On Wed, Jun 9, 2010 at 6:16 PM, Luciano Resende <lu...@gmail.com> wrote:
>
> On Sun, Jun 6, 2010 at 10:35 AM, Luciano Resende <lu...@gmail.com> wrote:
> > On Wed, Jun 2, 2010 at 9:13 PM, Henry Saputra <he...@gmail.com> wrote:
> >> +1 for making Album and Gallery as separate object model.
> >>
> >> I think this is inline with questions from others regarding Album and
> >> Gallery SCA services act as creator, object model, and service providers.
> >>
> >> -Henry
> >>
> >>
> >> On Mon, May 31, 2010 at 5:07 PM, Luciano Resende <lu...@gmail.com>wrote:
> >>
> >>> On Sun, May 16, 2010 at 11:22 AM, Luciano Resende <lu...@gmail.com>
> >>> wrote:
> >>> > I'd like to start working on defining a more robust API to access
> >>> > photoArk galleries, I'm planning to start by creating a new module
> >>> > (most likely a copy of current photark module) to avoid disrupting the
> >>> > current web application. I'd start by applying REST with JSON as the
> >>> > default wire format, and once we are ok with the new API, we could
> >>> > start migrating the existent app to use this new API.
> >>> >
> >>> > Thoughts ?
> >>> >
> >>>
> >>>
> >>> I have started playing with a REST API for PhotArk at my sandbox [1].
> >>>
> >>> I have started by introducing a clear separation of Model and
> >>> Services, and you can see that I created things like Gallery, Album
> >>> and Image as pure model objects. This will makes things clear and
> >>> improve performance by allowing more atomic client/server
> >>> communications with the Gallery/Album services.
> >>>
> >>> The second area is applying REST and Hypermedia principles to our API,
> >>> and the idea is that client (such as our UI) would interact with the
> >>> PhotArk gallery treating it as resources, and a call to retrieve
> >>>
> >>> GET http://localhost:8085/gallery
> >>>
> >>> would get a response similar to :
> >>>
> >>> {
> >>> "albums": [
> >>> {
> >>> "ref": "http://localhost:8080/gallery/album1",
> >>> "name": "Album 1",
> >>> "coverImageRef": null
> >>> },
> >>> {
> >>> "ref": "http://localhost:8080/gallery/album2",
> >>> "name": "Album 2",
> >>> "coverImageRef": null
> >>> }
> >>> ]
> >>> }
> >>>
> >>> Note that this initial response has all the information to build the
> >>> "gallery index" with a list of all available albums, and also provides
> >>> direct link to calling further service api to retrieve extra
> >>> information (e.g the album details via album:ref attribute ).
> >>>
> >>> Please let me know your thoughts on this, and if people are ok with
> >>> this direction, I'll start investigating what's the best way to
> >>> integrate this to trunk.
> >>>
> >>> [1]
> >>> http://svn.apache.org/repos/asf/incubator/photark/sandbox/lresende/photark-rest/
> >>>
> >>>
> >>> --
> >
> > I'll create a new branch (photark-rest) and start to apply these
> > changes in parallel to trunk to avoid breakages of the current
> > functionality.
> >
> >
>
> And some thoughts on the direction being taken available at
>
> https://cwiki.apache.org/confluence/display/PHOTARKxWIKI/PhotArk+REST+API
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
Re: PhotArk Gallery API
Posted by Luciano Resende <lu...@gmail.com>.
On Sun, Jun 6, 2010 at 10:35 AM, Luciano Resende <lu...@gmail.com> wrote:
> On Wed, Jun 2, 2010 at 9:13 PM, Henry Saputra <he...@gmail.com> wrote:
>> +1 for making Album and Gallery as separate object model.
>>
>> I think this is inline with questions from others regarding Album and
>> Gallery SCA services act as creator, object model, and service providers.
>>
>> -Henry
>>
>>
>> On Mon, May 31, 2010 at 5:07 PM, Luciano Resende <lu...@gmail.com>wrote:
>>
>>> On Sun, May 16, 2010 at 11:22 AM, Luciano Resende <lu...@gmail.com>
>>> wrote:
>>> > I'd like to start working on defining a more robust API to access
>>> > photoArk galleries, I'm planning to start by creating a new module
>>> > (most likely a copy of current photark module) to avoid disrupting the
>>> > current web application. I'd start by applying REST with JSON as the
>>> > default wire format, and once we are ok with the new API, we could
>>> > start migrating the existent app to use this new API.
>>> >
>>> > Thoughts ?
>>> >
>>>
>>>
>>> I have started playing with a REST API for PhotArk at my sandbox [1].
>>>
>>> I have started by introducing a clear separation of Model and
>>> Services, and you can see that I created things like Gallery, Album
>>> and Image as pure model objects. This will makes things clear and
>>> improve performance by allowing more atomic client/server
>>> communications with the Gallery/Album services.
>>>
>>> The second area is applying REST and Hypermedia principles to our API,
>>> and the idea is that client (such as our UI) would interact with the
>>> PhotArk gallery treating it as resources, and a call to retrieve
>>>
>>> GET http://localhost:8085/gallery
>>>
>>> would get a response similar to :
>>>
>>> {
>>> "albums": [
>>> {
>>> "ref": "http://localhost:8080/gallery/album1",
>>> "name": "Album 1",
>>> "coverImageRef": null
>>> },
>>> {
>>> "ref": "http://localhost:8080/gallery/album2",
>>> "name": "Album 2",
>>> "coverImageRef": null
>>> }
>>> ]
>>> }
>>>
>>> Note that this initial response has all the information to build the
>>> "gallery index" with a list of all available albums, and also provides
>>> direct link to calling further service api to retrieve extra
>>> information (e.g the album details via album:ref attribute ).
>>>
>>> Please let me know your thoughts on this, and if people are ok with
>>> this direction, I'll start investigating what's the best way to
>>> integrate this to trunk.
>>>
>>> [1]
>>> http://svn.apache.org/repos/asf/incubator/photark/sandbox/lresende/photark-rest/
>>>
>>>
>>> --
>
> I'll create a new branch (photark-rest) and start to apply these
> changes in parallel to trunk to avoid breakages of the current
> functionality.
>
>
And some thoughts on the direction being taken available at
https://cwiki.apache.org/confluence/display/PHOTARKxWIKI/PhotArk+REST+API
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: PhotArk Gallery API
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Jun 2, 2010 at 9:13 PM, Henry Saputra <he...@gmail.com> wrote:
> +1 for making Album and Gallery as separate object model.
>
> I think this is inline with questions from others regarding Album and
> Gallery SCA services act as creator, object model, and service providers.
>
> -Henry
>
>
> On Mon, May 31, 2010 at 5:07 PM, Luciano Resende <lu...@gmail.com>wrote:
>
>> On Sun, May 16, 2010 at 11:22 AM, Luciano Resende <lu...@gmail.com>
>> wrote:
>> > I'd like to start working on defining a more robust API to access
>> > photoArk galleries, I'm planning to start by creating a new module
>> > (most likely a copy of current photark module) to avoid disrupting the
>> > current web application. I'd start by applying REST with JSON as the
>> > default wire format, and once we are ok with the new API, we could
>> > start migrating the existent app to use this new API.
>> >
>> > Thoughts ?
>> >
>>
>>
>> I have started playing with a REST API for PhotArk at my sandbox [1].
>>
>> I have started by introducing a clear separation of Model and
>> Services, and you can see that I created things like Gallery, Album
>> and Image as pure model objects. This will makes things clear and
>> improve performance by allowing more atomic client/server
>> communications with the Gallery/Album services.
>>
>> The second area is applying REST and Hypermedia principles to our API,
>> and the idea is that client (such as our UI) would interact with the
>> PhotArk gallery treating it as resources, and a call to retrieve
>>
>> GET http://localhost:8085/gallery
>>
>> would get a response similar to :
>>
>> {
>> "albums": [
>> {
>> "ref": "http://localhost:8080/gallery/album1",
>> "name": "Album 1",
>> "coverImageRef": null
>> },
>> {
>> "ref": "http://localhost:8080/gallery/album2",
>> "name": "Album 2",
>> "coverImageRef": null
>> }
>> ]
>> }
>>
>> Note that this initial response has all the information to build the
>> "gallery index" with a list of all available albums, and also provides
>> direct link to calling further service api to retrieve extra
>> information (e.g the album details via album:ref attribute ).
>>
>> Please let me know your thoughts on this, and if people are ok with
>> this direction, I'll start investigating what's the best way to
>> integrate this to trunk.
>>
>> [1]
>> http://svn.apache.org/repos/asf/incubator/photark/sandbox/lresende/photark-rest/
>>
>>
>> --
I'll create a new branch (photark-rest) and start to apply these
changes in parallel to trunk to avoid breakages of the current
functionality.
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: PhotArk Gallery API
Posted by Henry Saputra <he...@gmail.com>.
+1 for making Album and Gallery as separate object model.
I think this is inline with questions from others regarding Album and
Gallery SCA services act as creator, object model, and service providers.
-Henry
On Mon, May 31, 2010 at 5:07 PM, Luciano Resende <lu...@gmail.com>wrote:
> On Sun, May 16, 2010 at 11:22 AM, Luciano Resende <lu...@gmail.com>
> wrote:
> > I'd like to start working on defining a more robust API to access
> > photoArk galleries, I'm planning to start by creating a new module
> > (most likely a copy of current photark module) to avoid disrupting the
> > current web application. I'd start by applying REST with JSON as the
> > default wire format, and once we are ok with the new API, we could
> > start migrating the existent app to use this new API.
> >
> > Thoughts ?
> >
>
>
> I have started playing with a REST API for PhotArk at my sandbox [1].
>
> I have started by introducing a clear separation of Model and
> Services, and you can see that I created things like Gallery, Album
> and Image as pure model objects. This will makes things clear and
> improve performance by allowing more atomic client/server
> communications with the Gallery/Album services.
>
> The second area is applying REST and Hypermedia principles to our API,
> and the idea is that client (such as our UI) would interact with the
> PhotArk gallery treating it as resources, and a call to retrieve
>
> GET http://localhost:8085/gallery
>
> would get a response similar to :
>
> {
> "albums": [
> {
> "ref": "http://localhost:8080/gallery/album1",
> "name": "Album 1",
> "coverImageRef": null
> },
> {
> "ref": "http://localhost:8080/gallery/album2",
> "name": "Album 2",
> "coverImageRef": null
> }
> ]
> }
>
> Note that this initial response has all the information to build the
> "gallery index" with a list of all available albums, and also provides
> direct link to calling further service api to retrieve extra
> information (e.g the album details via album:ref attribute ).
>
> Please let me know your thoughts on this, and if people are ok with
> this direction, I'll start investigating what's the best way to
> integrate this to trunk.
>
> [1]
> http://svn.apache.org/repos/asf/incubator/photark/sandbox/lresende/photark-rest/
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>
Re: PhotArk Gallery API
Posted by Luciano Resende <lu...@gmail.com>.
On Sun, May 16, 2010 at 11:22 AM, Luciano Resende <lu...@gmail.com> wrote:
> I'd like to start working on defining a more robust API to access
> photoArk galleries, I'm planning to start by creating a new module
> (most likely a copy of current photark module) to avoid disrupting the
> current web application. I'd start by applying REST with JSON as the
> default wire format, and once we are ok with the new API, we could
> start migrating the existent app to use this new API.
>
> Thoughts ?
>
I have started playing with a REST API for PhotArk at my sandbox [1].
I have started by introducing a clear separation of Model and
Services, and you can see that I created things like Gallery, Album
and Image as pure model objects. This will makes things clear and
improve performance by allowing more atomic client/server
communications with the Gallery/Album services.
The second area is applying REST and Hypermedia principles to our API,
and the idea is that client (such as our UI) would interact with the
PhotArk gallery treating it as resources, and a call to retrieve
GET http://localhost:8085/gallery
would get a response similar to :
{
"albums": [
{
"ref": "http://localhost:8080/gallery/album1",
"name": "Album 1",
"coverImageRef": null
},
{
"ref": "http://localhost:8080/gallery/album2",
"name": "Album 2",
"coverImageRef": null
}
]
}
Note that this initial response has all the information to build the
"gallery index" with a list of all available albums, and also provides
direct link to calling further service api to retrieve extra
information (e.g the album details via album:ref attribute ).
Please let me know your thoughts on this, and if people are ok with
this direction, I'll start investigating what's the best way to
integrate this to trunk.
[1] http://svn.apache.org/repos/asf/incubator/photark/sandbox/lresende/photark-rest/
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: PhotArk Gallery API
Posted by Luciano Resende <lu...@gmail.com>.
On Sunday, May 16, 2010, Henry Saputra <he...@gmail.com> wrote:
> Are you going to use the Tuscany REST binding? I dont think its in the M4
> release of Tuscany that PhotArk is using, does it?
>
> - Henry
>
Now that we have a branch for PhotArk M2 release, we can easily move
to use Tuscany snapshot while they wrap up their 2x M5 release.
Thoughts ?
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: PhotArk Gallery API
Posted by Henry Saputra <he...@gmail.com>.
Are you going to use the Tuscany REST binding? I dont think its in the M4
release of Tuscany that PhotArk is using, does it?
- Henry
On Sun, May 16, 2010 at 11:22 AM, Luciano Resende <lu...@gmail.com>wrote:
> I'd like to start working on defining a more robust API to access
> photoArk galleries, I'm planning to start by creating a new module
> (most likely a copy of current photark module) to avoid disrupting the
> current web application. I'd start by applying REST with JSON as the
> default wire format, and once we are ok with the new API, we could
> start migrating the existent app to use this new API.
>
> Thoughts ?
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>