headers
Randy Letness | 2 Feb 2009 03:24
Favicon

Re: Cosmo search patches

Avner,

I'm looking at the server side changes, which are in 
ItemCollectionAdapter and BaseItemFeedGenerator. 

In ItemCollectionAdapter I understand getSearchFeed(), which is what 
will be called if I issue a request like:

http://server:8080/chandler/atom/collection/abc/full/eim-json?searchType=basicSearch&query=foo

But I don't quite understand when the search logic in 
createQueryFilter() will be called.  There seem to be other search types 
(body, title, etc), but I'm confused about how these would be accessed?  
Can you give an example?

-Randy

Avner Shanan wrote:
> Here are the patches that add search functionality to Cosmo.  Please
> let me know if you see something wrong with them.
>
Permalink | Reply | 6 comments |
headers
Avner Shanan | 4 Feb 2009 11:10
Picon

Re: Cosmo search patches

My apologies, that code doesn't actually do anything anymore.  That
code was set up for advanced search, but I ended up going a different
route that was not included in this patch.  I thought I had removed
that code, but apparently I didn't.  In the working prototype of
advanced search that code has been removed from creatQueryFilter() and
moved to its own method (called generateAdvancedSearchFeed()).  The
advanced search works, but it needs integration with the UI.  If
someone who has a good feel for the hub's UI would like to help me do
that, I would greatly appreciate the help.  I haven't looked at it in
a little while, but I remember having a lot of trouble getting the UI
to do what I wanted it to (besides, there should probably be someone
with a more professional eye watching over any changes to the UI).

On Sun, Feb 1, 2009 at 8:24 PM, Randy Letness <randy <at> osafoundation.org> wrote:
> Avner,
>
> I'm looking at the server side changes, which are in
> ItemCollectionAdapter and BaseItemFeedGenerator.
>
> In ItemCollectionAdapter I understand getSearchFeed(), which is what
> will be called if I issue a request like:
>
> http://server:8080/chandler/atom/collection/abc/full/eim-json?searchType=basicSearch&query=foo
>
> But I don't quite understand when the search logic in
> createQueryFilter() will be called.  There seem to be other search types
> (body, title, etc), but I'm confused about how these would be accessed?
> Can you give an example?
>
> -Randy
(Continue reading)

Permalink | Reply | 5 comments |
headers
Randy Letness | 4 Feb 2009 15:46
Favicon

Re: Cosmo search patches

Ok cool.  I'll probably move it into its own method for now and check 
the server side changes in later today.  I had some issues using the 
patch you submitted because it had a bunch of changes not related to the 
search functionality so I basically picked out that functionality and 
manually merged it in.  I've tested the base search functionality using 
curl and it seems to work.

I didn't even attempt to merge in the ui changes and test out because 
I'm not familiar with that code base.  Maybe Jeffrey or someone can help 
out and merge the ui changes.

-Randy

Avner Shanan wrote:
> My apologies, that code doesn't actually do anything anymore.  That
> code was set up for advanced search, but I ended up going a different
> route that was not included in this patch.  I thought I had removed
> that code, but apparently I didn't.  In the working prototype of
> advanced search that code has been removed from creatQueryFilter() and
> moved to its own method (called generateAdvancedSearchFeed()).  The
> advanced search works, but it needs integration with the UI.  If
> someone who has a good feel for the hub's UI would like to help me do
> that, I would greatly appreciate the help.  I haven't looked at it in
> a little while, but I remember having a lot of trouble getting the UI
> to do what I wanted it to (besides, there should probably be someone
> with a more professional eye watching over any changes to the UI).
>
Permalink | Reply | 4 comments |
headers
Avner Shanan | 4 Feb 2009 18:49
Picon

Re: Cosmo search patches

On Wed, Feb 4, 2009 at 8:46 AM, Randy Letness <randy <at> osafoundation.org> wrote:
>I had some issues using the
> patch you submitted because it had a bunch of changes not related to the
> search functionality so I basically picked out that functionality and
> manually merged it in.  I've tested the base search functionality using
> curl and it seems to work.

Yeah, I was wondering what all of that was.  Sorry about that.

> I didn't even attempt to merge in the ui changes and test out because
> I'm not familiar with that code base.  Maybe Jeffrey or someone can help
> out and merge the ui changes.

I didn't include the advanced search UI code.  Its in a 'working
prototype' state at the moment.  I resorted to a fairly ugly hack,
just so I could check that the code was indeed working (I basically
replaced the AwesomeBox widget with my advancedSearch widget).

> -Randy
>
> Avner Shanan wrote:
>> My apologies, that code doesn't actually do anything anymore.  That
>> code was set up for advanced search, but I ended up going a different
>> route that was not included in this patch.  I thought I had removed
>> that code, but apparently I didn't.  In the working prototype of
>> advanced search that code has been removed from creatQueryFilter() and
>> moved to its own method (called generateAdvancedSearchFeed()).  The
>> advanced search works, but it needs integration with the UI.  If
>> someone who has a good feel for the hub's UI would like to help me do
>> that, I would greatly appreciate the help.  I haven't looked at it in
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeffrey Harris | 5 Feb 2009 00:51
Favicon
Gravatar

Re: Cosmo search patches

Hi Avner,

> Yeah, I was wondering what all of that was.  Sorry about that.

I think the command I suggested for diffing only works if your master
branch has been rebased to the same remote version as your branch, looks
like that wasn't the case for you.

For future reference, probably a more reliable approach would be to find
your first relevant commit's ID (call it XYZ123) and do:

git diff XYZ123..HEAD

Anyway, rather than following that path, I thought I'd use git.
Unfortunately, git-am was unhappy with your patch, because it looks like
many of your commits included spurious changes to emacs backup files
(ending in a tilde) and a few built-by-dojo files.  You probably want to
globally ignore those files.

Anyway, I edited that stuff out of your patches, and have a working
branch with your changes.

I think what you've got should work fine.  I'm going to change the text
in the AwesomeBox to expose the /f functionality, but I don't think I'm
going to change anything else.

A few notes:

- You're using getItems instead of getDashboardItems.  I think that's
pretty much fine, except that
(Continue reading)

Permalink | Reply | 2 comments |
headers
Randy Letness | 5 Feb 2009 02:24
Favicon

Re: Cosmo search patches

Ok, server side bits are checked into trunk.  I left the advanced search 
stuff out for now.

-Randy

Jeffrey Harris wrote:
> Randy - I'm not totally clear which of Avner's server-side changes are
> actually used, if you want to check in the important server-side bits,
> I'll check in the UI.
>
Permalink | Reply | 0 comments |
headers
Jon Steinhart | 5 Feb 2009 06:53
Favicon

Help importing data into cosmo server

I've been playing around with cosmo/chandler.  One of the things that I'm trying to do is add functionality that allows me to import calendars from systems.  I've been through all the documentation and unless I'm missing something there just isn't enough information there.  So I'm hoping that y'all can give me some pointers that'll save me from having to figure it all out by reading the source code as that'll take a while.

I've tried hitting the server with a MKCALENDAR as per the sketchy CosmoCaldav page and it returns Method MKCALENDAR is not defined in RFC 2068 and is not supported by the Servlet API.

I next looked at CosmoMorseCode under Publish Collection.  This appears to rely on EIM, but I couldn't find any definitive information on that.  It also isn't clear where UUIDs come from; can a client pick any unused value or is there some way to ask the server for one?

Next I tried spying on the cosmo/chandler interaction.  That appears to use some EIM+JSON stuff for which I could find no documentation, and I noticed that the namespace uri that it uses does not exist.  I didn't find any usable documentation on this, but I did find a blog entry by bcm that seemed to indicate that this stuff wasn't the best choice.

So I'd appreciate any pointers on how to go about getting data into cosmo.  Using 1.1.0.

Thanks,
    Jon

_______________________________________________
cosmo-dev mailing list
cosmo-dev <at> lists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
Permalink | Reply | 4 comments |
headers
Jeffrey Harris | 5 Feb 2009 20:47
Favicon
Gravatar

Re: Help importing data into cosmo server

Hi Jon,

If you've already created a collection and you want to import a
calendar, I think your best bet is to use the iCalendar import code
Randy wrote:

http://markmail.org/message/tttsy47ngn4dilxi

Actually, that message is about POSTing a URL, but Randy mentions you
can also directly POST an icalendar payload.

To create a calendar, I think CalDAV is your best bet.

> I've tried hitting the server with a MKCALENDAR as per the sketchy
> CosmoCaldav page and it returns /Method MKCALENDAR is not defined in RFC
> 2068 and is not supported by the Servlet API.

Sounds like you're targeting a resource that doesn't support MKCALENDAR.
 You want to apply MKCALENDAR to a child of a user's home CalDAV collection.

See http://chandlerproject.org/Projects/WebUIProtocolUrls

If an authenticated
MKCALENDAR .../dav/users/≤username>/<some_calendar_name>

doesn't give you a 201, then there is a problem.

> /I next looked at CosmoMorseCode under Publish Collection.  This appears
> to rely on EIM, but I couldn't find any definitive information on that. 
> It also isn't clear where UUIDs come from; can a client pick any unused
> value or is there some way to ask the server for one?

Have you looked at

http://chandlerproject.org/Projects/EimmlSpec

and

http://chandlerproject.org/Projects/EimJsonSpec
?

Not that those will actually get you over the hump of EIM (again, use
CalDAV), but they're all that I know of in terms of Cosmo EIM documentation.

Sincerely,
Jeffrey
Permalink | Reply | 3 comments |
headers
Jon Steinhart | 5 Feb 2009 22:03
Favicon

Re: Help importing data into cosmo server

Jeffrey Harris wrote:
To create a calendar, I think CalDAV is your best bet.
I've tried hitting the server with a MKCALENDAR as per the sketchy CosmoCaldav page and it returns /Method MKCALENDAR is not defined in RFC 2068 and is not supported by the Servlet API.
Sounds like you're targeting a resource that doesn't support MKCALENDAR. You want to apply MKCALENDAR to a child of a user's home CalDAV collection. See http://chandlerproject.org/Projects/WebUIProtocolUrls If an authenticated MKCALENDAR .../dav/users/<username>/<some_calendar_name> doesn't give you a 201, then there is a problem.
Thanks for the help.  Some slight progress.  Next question is, what's a collection.  I'm sending a MKCALENDAR to http://localhost:8080/chandler/dav/users/jon/new, where jon is my username
and new is a new calendar name.  The server is returning "Resource /users/jon is not a collection".  Maybe I can only create new calendars under old ones?  So I have an existing calendar named test, and try http://localhost:8080/chandler/dav/users/jon/test/new which yields "One or more intermediate collections must be created".

Am I getting confused by the many conflicting meanings of "collection"?  I am under the impression that .../dav/users/jon was by definition a webdav collection.

Thanks,
    Jon
_______________________________________________
cosmo-dev mailing list
cosmo-dev <at> lists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
Permalink | Reply | 2 comments |
headers
Jeffrey Harris | 5 Feb 2009 23:01
Favicon
Gravatar

Tagging 1.2

Hi Randy and Cosmo folks,

I'd like to tag the current trunk as 1.2 (which is running live on
trunk.osaf.us), but I've bumped into a few problems.

- There are a few cosmetic CSS issues related to the version of dojo
we're using, I'm working on fixing those now (took me several days to
get my local cosmo tree to work again, but I think it's working now)

- I'd like to turn on periodic email notifications, but they don't
appear to be working.  In the past I had issues with emails getting
marked as spam, but the server's mail log doesn't show any recent
legitimate traffic, so I don't think that's it.

Looking deeper, it appears that lab's nameserver lookup is failing to
find an MX record for osafoundation.org (is it possible BIND is
misconfigured on that machine, Jared?), so a test email to
jeffrey <at> osafoundation.org sits in the mail queue, but there aren't any
hourly notifications in the queue so I don't think that's the issue with
notifications.

All in all, I'm stumped about what's happening with notifications.  If
there were errors where would they be logged?  Any clues or thoughts
would be welcome.

Sincerely,
Jeffrey
Permalink | Reply | 1 comment |

Gmane