OKAPI Project - API for OpenCaching sites

[oliver]

Catching Exceptions:
Do i have to parse the entire content of the response, or could we introduce a prefix?

Example:

For cache_code-invaild, i get currently the response "Parameter 'cache_code' has invalid value: This cache does not exist."

If you send me "CacheCodeInvalidException: Parameter 'cache_code' has invalid value: This cache does not exist.", i could check for string before : and throw exactly that exception. This would also enable us to throw localized exceptions.

Or should be use a JSON-structured-response?

My current code (entire string is compared):

Code: [Auswählen]

Friend Class KnownExceptions
Public Const CacheCodeInvalid As String = "Parameter 'cache_code' has invalid value: This cache does not exist."
Public Const ConsumerKeyInvalid As String = "Parameter 'consumer_key' has invalid value: Consumer does not exist."

Public Shared Function GetKnwonException(ByVal ex As BadRequestException) As Exception
Select Case ex.Message
Case CacheCodeInvalid
Return New CacheCodeInvalidException(ex.Message, ex)
Case ConsumerKeyInvalid
Return New ConsumerKeyInvalidException(ex.Message, ex)
Case Else
Return ex
End Select
End Function
End Class


[oliver]

A real issue: I dont get okapi running on my development machine, because okapi requires that OC source code is installed in DOCUMENT_ROOT of apache. Now i need to reconfigure everything to support virtual hosts on my development machine

[oliver]

Okay, okapi is now running in my development machine ...
... i have modified the geocaches-routine to support our database layout (via Configuration class).

I send it with a private message to you.
Maybe you want to modify some naming conventions etc.

Please, let me know if that is a way to implement database differences directly within okapi.

[oliver]

I submitted my first issue directly to google-code
http://code.google.com/p/opencaching-api/issues/detail?id=58

[wrygiel]

> Catching Exceptions:
> Do i have to parse the entire content of the response, or could we
> introduce a prefix?

What you want is for OKAPI to return a parsable (and extendable)
object with the details of the exception, instead of a single message.

In fact, I thought of that, but I didn't think anyone would be
interested in such a fine-grained exception control. Every bad request
is still a bad request, I am not sure if these additional exception
classes would actually do you any good. They all will be subclassing
BadRequest, and BadRequest is probably the only thing you will need to
catch (there is no need for special handling for other subclasses of
this exception).

I added an issue, but with a low-priority for now.
http://code.google.com/p/opencaching-api/issues/detail?id=59

> A real issue: I dont get okapi running on my development machine,
> because okapi requires that OC source code is installed in
> DOCUMENT_ROOT of apache. Now i need to reconfigure everything to
> support virtual hosts on my development machine

You are probably right. I haven't tested it in any other
configuration. Feel free to send me a patch.

> Okay, okapi is now running in my development machine ... ... i have
> modified the geocaches-routine to support our database layout (via
> Configuration class).
>
> I send it with a private message to you. Maybe you want to modify
> some naming conventions etc.

Okay, I'll look into it.

> I submitted my first issue directly to google-code
> http://code.google.com/p/opencaching-api/issues/detail?id=58

Thanks

[wrygiel]

1.

I don't want for the configuration file to be kept within the "okapi"
directory. This could complicate updates (currently okapi can be
updated by just deleting it, and loading a new copy). Also, from what
I know, all OC settings are kept in the lib/settings.inc.php - OKAPI
will try to read it from there.

2.

You proposed two options: caches_stat_option and caches_have_votes.

Oc.pl uses caches_stat_option=1 and caches_have_votes=1.
Oc.de uses caches_stat_option=2 and caches_have_votes=0.

But I think there are no installations which will use any OTHER
combinations of these two flags. Am I correct? Do you think there will
EVER be such installations?

If not, I would still prefer to have it simpler:

if (oc.de) { sql(..) } else { sql(..) }.

I know having tons of settings seems professional, but I'd like to
keep things simple. SQL queries dependant on such multiple flags are
not simple at all.

As I understand, there are only two major OC ports - yours and ours.
Every other OC is based on oc.pl OR oc.de. That's why, the "if
(oc.de)" solution seems the right one here.

Having other settings would create an illusion, that other OC nodes
could use some of oc.pl code, and some of the oc.de code. But I think,
this *IS* an illusion. I think no one - except possibly us - will ever
try to merge any parts of oc.pl and oc.de.

I used the "if (oc.de)" approach (at least for now). This will
simplify any changes you will have to make to get it working on oc.de.

3.

Added some docs.


See here:
http://code.google.com/p/opencaching-api/source/browse/trunk/okapi/settings.php
and here:
http://code.google.com/p/opencaching-api/source/detail?r=81

[mic@]

Having other settings would create an illusion, that other OC nodes
could use some of oc.pl code, and some of the oc.de code. But I think,
this *IS* an illusion. I think no one - except possibly us - will ever
try to merge any parts of oc.pl and oc.de.

No one is OlofL 
http://forum.geocaching-network.com/index.php?topic=1203.0

[wrygiel]

No one is OlofL 
http://forum.geocaching-network.com/index.php?topic=1203.0

Can you tell me, in short, what's the project's intent? I haven't read that topic, but I assumed it was about merging your databases and moving oc.se to oc.de. Now, as I understand, the project is an attempt to include SOME (?) changes from oc.de into an oc.pl-based distribution?

[mic@]

Can you tell me, in short, what's the project's intent?

short: Merging oc.pl and oc.de code.

long:

The outline of this subproject is to:
- Create a branch (se-dev) from the oc.de source (oc-server). From a version control perspective this can be seen as a private branch for isolated development. The word "private" only means that the oc.de (oc-server) is unaffected during the development.
- Add features from the current oc.se source into the new se-dev-branch
- During this time work can still be done on the oc.de source (oc-server) and this can be merged to the new se-dev-branch.
- When the new se-dev-branch is stable enough for production oc.se will go live on this
- After the go live, this branch will be reintegrated back in the oc.de source (oc-server) and both oc.de and oc.se will go live on a common source.

[wrygiel]

So, after the project finishes:
- oc.de will contain some additional features from oc.se/oc.pl,
- oc.se will start using oc.de code,
But:
- oc.pl (and some others) will still be using "old" oc.pl code (unless they choose to switch completely to the oc.de branch).

Am I correct?

[mic@]

- oc.de will contain some additional features from oc.se/oc.pl

Yes, we allready got some oc.pl-features due to this merge, e.g. the personal cache note.

- oc.se will start using oc.de code

Better wording would be "using oc.de/oc.pl-code mix".

- oc.pl (and some others) will still be using "old" oc.pl code (unless they choose to switch completely to the oc.de branch).

Yes, I think so.

[wrygiel]

>> - oc.se will start using oc.de code
>
> Better wording would be "using oc.de/oc.pl-code mix".

What I meant was: Oc.se will start using code from oc.de official
repository. (Oc.de will contain the oc.pl+oc.de merged code be then.)

>> - oc.pl (and some others) will still be using "old" oc.pl code
>> (unless they choose to switch completely to the oc.de
>> branch).
>
> Yes, I think so.

Then, in the end, we might say that we still end up with two branches:
"oc.de" (merged one) and "oc.pl". But with one big difference: "oc.de"
will have many features from "oc.pl", and the switch from "oc.pl" to
"oc.de" will be easier.

Hopefully, when you finish this merge, oc.pl (and others) will choose
to switch to oc.de branch. And ONLY THEN all OCs will have a common
repository.

Currently OKAPI uses conditions such as this one:

if (Settings::get('OC_BRANCH') == 'oc.de') {
   ...
} elseif (Settings:get('OC_BRANCH') == 'oc.pl') {
   ...
}

I think, we need a third value for your project. We might call it
'oc-merge-project':

if (Settings::get('OC_BRANCH') == 'oc-merge-project') {
   ...
} elseif (Settings:get('OC_BRANCH') == 'oc.de') {
   ...
} elseif (Settings:get('OC_BRANCH') == 'oc.pl') {
   ...
}

When oc.de decides to adopt your merge branch, it will switch their
OC_BRANCH value to 'oc-merge-project', and we will be able to remove
'oc.de' parts from OKAPI. Then (I hope), oc.pl (and others) will do
the same thing.

[oliver]

1.

I don't want for the configuration file to be kept within the "okapi"
directory. This could complicate updates (currently okapi can be
updated by just deleting it, and loading a new copy). Also, from what
I know, all OC settings are kept in the lib/settings.inc.php - OKAPI
will try to read it from there.

Okay.

2.

You proposed two options: caches_stat_option and caches_have_votes.

Oc.pl uses caches_stat_option=1 and caches_have_votes=1.
Oc.de uses caches_stat_option=2 and caches_have_votes=0.

But I think there are no installations which will use any OTHER
combinations of these two flags. Am I correct? Do you think there will
EVER be such installations?

Yes, it could. And i hope so. The migration of new oc.pl-code to git-repository is still in progress. The votes might get migrated in future. oc.pl might decide to migrate some of our features in future.

Of course, its not "oc.de code", we should name it "git-repository".

We have at least 3 repositories:

1) oc.pl-svn. They have own development team and its used by several sites.

2) The git-repository with different branches (based on oc.de-svn)
=> oc.se/oc.no runs from that repository
=> all future development will be done in git-repository

3) oc.de-svn with different branches
=> The oc.de production server will be moved to git repository, as soon as the code is compatible. We have most of that migration done. So at the end of this year, oc.de may use the source from the git repository
=> oc.nl runs also from that repository and after oc.de runs from git, i will try to migrate oc.nl to the git-repository

As I understand, there are only two major OC ports - yours and ours.
Every other OC is based on oc.pl OR oc.de. That's why, the "if
(oc.de)" solution seems the right one here.

Both solutions have disadvantages ...

[oliver]

So, after the project finishes:
- oc.de will contain some additional features from oc.se/oc.pl,
- oc.se will start using oc.de code,
But:
- oc.pl (and some others) will still be using "old" oc.pl code (unless they choose to switch completely to the oc.de branch).

Am I correct?

oc.se already runs the code from git-repository. The git-repository is base on smarty. So all php-files migrated are "totaly different". There are still some unported files like "search.php" and "newcache.php".

What oc.se did is, that they used the "new" oc.de code with smarty and integrated some new oc.pl features. Most important: the additional waypoints. The additional waypoints are online/runnning at oc.se and oc.de, but oc.nl does not have it until now, because of some local modifications that make update complex ...

[mic@]

There are some features which OKAPI are not supporting,
e.g. picture upload within log or maintenance logging (german "kann gesucht werden").
Is it planned to integrate these features soon?