Moving 'Network File Activity' to Application - new Class Name

[mikeradka]

We are moving the Network File Activity class from the Network category to the Application category (by way of deprecation to keep it non-breaking).

In doing so, we have to change the name to make it suitable for what this class represents:

...the actions taken by file management applications, including file sharing servers like Sharepoint and services such as Box, MS OneDrive, or Google Drive.

[mavam]

Neither suggestions feel intuitive to me.

• "Hosting" suggests that file management is the primary function of the service. Is the goal to limit to this type of file activity? It seems too narrow.

• "Sync" suggests we're synchronizing a state to get two entities caught up. Again, very specific. Is this needed?

I suggest something more generic: File Transfer. If you want to capture a backup event that has a lot of transfers (= a synchronization a la rsync), then there's still an option for separate for a separate event that (optionally) points to multiple individual File Transfer events.

[mikeradka]

This is not a class to simply log file transfers. This is a class specific to Cloud File Storage application logs. File transfer protocols are handled in the Network class.

[zschmerber]

All of the logs for box, google drive, azure ext.. That would technically fit into the application category, and are commonly available are audit logs.

It seems that most of what is captured in the audit logs reflect what I see in Web Resources Activity and API Activity

So can we deprecate "Network File Activity" and just add the File Object into the Web Resource Activity and API activity? Or are we going this way to avoid breaking changes ?

[mavam]

Is the goal to represent the application log (Box event) or the underlying action (file transfer)?

[mikeradka]

The class already maps Box application logs and MS Onedrive logs. Please see the activities listed, as this class already serves a unique and necessary purpose - to map cloud file application service logs. These are not API logs nor are they the network file transfer logs. They are the logs these applications write in tracing their file upload/dowload/sync/unsync/and other functions. The log's focal point is the application layer, not the network or system layer.

[zschmerber]

@mikeradka Once moved will some of the inherited fields specific to network activity disappear?
for example app_name, connection_info

[mikeradka]

The class was only set to extend network activity in 1.1-dev, and that was only done when a request was made for all classes in the network category to extend the base network class. The Box and OneDrive events that are already mapped don't utilize these fields. Therefore, moving this class and no longer extending the base network attributes is non-breaking.

[pagbabian-splunk]

The functionality of the class is application layer file sharing and file syncing - the activities that would be logged either by a file sharing server like SharePoint or a cloud service like Box or Drive or OneDrive. The activity enum should best indicate what the overall class' semantics are, and a class name should correspond to that.

In this case, it's not a protocol level file transfer, or a data store storage, nor is it an OS file system level activity set. Personally I like File Sync & Share because that's what it was intended to map, but File Hosting happens to be what the service also does, and the management of those files. So I would go with either, but not a lower layer or more general name.

Web Resource Activity is more general (i.e. most but not all Sync & Share services are web based, or cloud hosted) and the activities are also more general, as are the resources. API Activity is even more general, and again, the activities aren't explicit.

[mikeradka]

Completed via #917