As of this morning, it looks as though the RESEARCH.BSS service holds about 105,000 files, of which approximately 95,000 are images from the Appleton office camera. Very cool. Now we just need to think of something to do with them.
I did create a massive (approaching gigabytes) animated GIF, but really need something to just assemble them all into an AVI or something similar.
Reference: BSS architecture and multimedia support
Good news, everyone! Jeff and I are discussing how to incorporate the ability for the BSS to better handle multimedia and large numbers of stored entities
Things I might want to avoid
- making the BSS a complete, and general persistence system, although that would make sense in the context of CygNext (I would argue).
- Extensive reliance on GNU-licensed OpenSource
- Biting off more than I can chew. Mmmm….eleventy-twelve donuts.
Attributes of the BSSOT
- It’s read-mostly
- Needs to be searchable
- Performance is key
- Easy to maintain
Things I want to investigate
- “overlay” directories – E.g. “View by date”, “View by location”, “View by <select image from <daterange> where avg_color is like <r,g,b>”, “View by is_near(<location>)”
- Lots of data. More than that. No, even more. Yes, like that, only with more on the edges.
- Studio helpers for retrieval, playback, search, …
BSS maintenance workbench
Differential data storage
Holographic (reliability) data storage (clustered/network)
Distributed and/or reliable file systems
Transparent storage and access mechanism for agents, applications, and users using WebDAV
- Show on map, stacked by time
- Silverlight embedded (tried this, btw, and it crashes Studio)
- Silverlight embedded in embedded IE browser control
- Flash embedded
Object versioning (via same architecture as current products: PNT->CVS->VHS) (Can I do this now? Investigate)
- Use of URIs as a resource address specification mechanism
- Support many-to-many (names<->objects)
Note: There is no CygNext. These are not the droids you are looking for. CygNext is my pet term for a theoretic “next” version of CygNet that does not have the limitations of the existing product, has better web/external integration, supports IPv6, and smells as fresh as a mountain spring. It’s not a project, it doesn’t exist, and I’m not pushing for it. OTOH, I’m not not pushing for it either.
Coda Distributed File System
Peter J. Braam
School of Computer Science,
Carnegie Mellon University
The Coda distributed file system is a state of the art experimental file system developed in the group of M. Satyanarayanan at Carnegie Mellon University. Numerous people contributed to Coda which now incorporates many features not found in other systems:Mobile Computing
- disconnected operation for mobile clients
- reintegration of data from disconnected clients
- bandwidth adaptation
- Failure Resilience
- read/write replication servers
- resolution of server/server conflicts
- handles of network failures which partition the servers
- handles disconnection of clients client
- Performance and scalability
- client side persistent caching of files, directories and attributes for high performance
- write back caching
- kerberos like authentication
- access control lists (ACL’s)
- Well defined semantics of sharing
- Freely available source code
Conceptual* architecture of a next-generation BSS optimized for storing image/media BLOBs. More than BLOBs, really. More like GOBs (Ginormulous OBjects, and yes, that’s really a word. Really. Really.)
In CAs, despite there being separate ‘server’ icons, functions like the Dropbox and the Library might really be on the same box, part of the same service, or both. This cartoon-style drawing is just to delineate the process-level functions.
The "Library” seems like it’s a support service for the “Librarian”. It would be built as a CygNet service, but no one except a Librarian would interact with it. Its only job would be to manage the “stacks”, where objects are stored.
- Green lines: control messages
- Blue lines: data messages
*Using my architecture nomenclature: Conceptual-Logical-Functional-Physical-Operational
sketch of a design for a UI to allow browsing alarms and associated images, or vice versa, via a variety of navigation mechanisms. Designed for use by pointer only, if necessary.
The red arrows mean “previous/next critical (red) alarm” and the yellow mean “previous/next warning”. You could extend this model to incorporate add’l graphic signifiers, to ease use on non-keyboard devices.