Github user joshelser commented on a diff in the pull request:
https://github.com/apache/incubator-ratis/pull/4#discussion_r212007378
--- Diff:
ratis-logservice/src/main/java/org/apache/ratis/logservice/api/ArchivedLog.java
---
@@ -0,0 +1,43 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.ratis.logservice.api;
+
+/**
+ * A {@link LogStream} which has been archived in some external
+ * system. This interface is parameterized to allow for implementations
+ * to use their own class to encapsulate how to find the archived log.
+ *
+ * In the majority of cases, this should be transparent to end-users, as
+ * the {@link LogStream} should hide the fact that this even exists.
+ * TODO maybe that means this should be client-facing at all?
+ *
+ * @param <T> A referent to the log on the external system.
+ */
+public interface ArchivedLog<T> extends AutoCloseable {
--- End diff --
Yeah, I was mulling over whether or not to even include it in this initial
drop.
I like the idea of a consistent API to read from Log, regardless of it
being "active" (still in the state machine) or "archived" (exported to some
remote storage).
> Log archiving is the feature HBase requires
I think that this is a generally reusable feature that users would like. It
would help keep the state machine "small" and consistent performance.
> HBase client will create archive subdirectory and will be moving old
files to this subdirectory
I think automated archival should be a feature that LogService provides.
HBase should be unaware that we are moving "segments" of data around.
> I want to enhance LogService with FileSystem-like API:
I have changes that have been sitting locally for too long. I'm
prioritizing getting them finished and then update this. I think being able to
think of the LogService like a FileSystem is nice. I'm curious if you have put
more thought about how the notion of "directories" might be used :)
---
